Mystery of jsonrpc call that never completes

Recently I came across an interesting problem (to say the least) where jsonrpc call would execute the error call back function, but did not provide the details.  Additionally (as the title suggests) Firebug showed that the call never completed. Firebug continues to show rotating ring next to this call. But server logs suggested that server not only received the call, but it also processed the request completely.

I googled for “jsonrpc never completes” (and other similar terms) But no one had faced the problem. Strange

Normally, when jsonrpc call executes error callback, there would be some error on the server (serving the rpc call) But in this case, the call went thru fine. No error on server.

So I started debugging. First place to look, check server logs. No error there. Added additional debug statements on server. Still no help.

Then I modified the client-side code. Checked if there were additional information in the response sent back. Nothing.

May be there was something wrong with this specific RPC. Just to isolate, I made another RPC, which was known to work at other places. I was so sure that problem would go away, that I was shocked that problem remained.

So clearly it wasn’t the RPC, but the way it was called. So I started looking at surrounding code. Wasn’t any different. So I went further up the stack. It turns out later in the chain – unconditional window.location.reload() was called. This was causing the browser to reload the page even before the jsonrpc would complete.

Looking back – it was obvious. So why did I write this post ? So that someone else who may come across such symptom in future, may have some tips to troubleshoot.

In case you are interested, this was part of this project

Related articles

• Debugging Javascript applications (markos.gaivo.net)
• Firebug Guide for Web Designers (sixrevisions.com)

Django 1.2.1 : Page Not Found :/

This was my first instance of installing Django and deploying a third party app on it. After deploying the Django-App, I started the app using “python manage.py runserver” It seemed to have started cause I got the following message :

Validating models…
0 errors found

Django version 1.2.1, using settings ‘xxx.settings’
Development server is running at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.

But when I visited the page http://127.0.0.1:8000/ (or http://127.0.0.1:8000/admin) I would get “Page Not Found :/” (or “Page Not Found :/admin” – depending on which page I tried to launch) Since I was trying this app for the first time, I suspected that this must be the problem with the app. I checked with other folks who worked on this project, but I couldn’t get any help.  While reading the Django documentation further – I came across an option to “runserver” command where one can start the server on non-default port. As part of troubleshooting, I just tried it, not hoping for much success, but it worked.

Now I am thinking why doesn’t the app work on default port, but works on non-default port. So I stopped the server (running on non-default port) and tried the URL again. I still got the “Page not found” error, and this made it clear that, some other server was listening on port 8000.  Eventually I was find out the process that was listening on port 8000 using the following command :

netstat -ao | findstr LISTENING

Option ‘0′ prints the process ID – I was able to find out the eecutable using ProcExp (which has replaced my Task Manager) On linux – use “grep” in place of “findstr” and “ps” can be used to find out the executable

What surprised me was even though some process is already listening on default port 8000, How did Django “runserver” did not give an error when it tries to bind to port 8000.  This can be reproduced easily by running two instances of same app (or two different apps) from two different terminals. Second instance should fail while binding to default port – and I expect it to show error – But it doesn’t. If it matters I was using Django 1.2.1 on Windows XP (Python 2.6)

All in all, It was very interesting to troubleshoot the problem.