Rubberband Wound

I had a couple drafted posts in WordPress that I’d forgotten about - including this one. The others aren’t all that great, so I’m leaving them alone for now, but I thought this was an idea worth getting out there. I don’t know exactly when I wrote this; I think it was about 6 to 8 weeks ago.

I’ve spent the last couple of days at work trying to fix an issue with an AJAX call that was failing if a user’s net connection dropped or the server hiccuped. The real problem was that this call was on a timer, updating on its own every 60 seconds without user intervention. Once any update didn’t come through, however, that was the end of the updates, the timer stopped running and the page stopped updating, with no real notice to the user. Since this is an extremely critical page in the application with potentailly far reaching consequences, it was necessary to make it more reliable.

The first step in improving this was updating the AJAX call - we’d written the page back in the early AJAX days (about 8 months ago) and were using DataRequestor. Prototype is our library of choice these days, and so much easier to work with, so I switched over the code. Thanks for Form.serialize it was a minor task, taking just minutes to get everything up and running properly again.

I tried a few techniques before finding something that worked - Ajax.PeriodicalUpdater worked, but was acting funny and I couldn’t pin down why. Finally, after trying to see if there were caching issues or if I’d overlooked a function somewhere that I didn’t realize I was calling, I realized what was happening. Ajax.PeriodicalUpdater doesn’t update the parameters it takes in on each call, which I foolishly assumed it would (though I have no idea why I did).

I had a search button I could click to force an update, so I’d change my search filters and update the content, only to see it suddenly switch back to the old information. After some head scratching and some reading I realized that each click was making a new PeriodicalUpdater, before long the content was constantly flicking from view to view as all the updaters ran over each other. Whoops.

And so came the switch to a normal Ajax.Updater called by the glorious PeriodicalExecuter. I swear, every day I find something new in Prototype that makes me that much more greatful to have it. With PeriodicalExecuter successfully running every interval, next came the big test. I unplugged the network cable, watched the Ajax call fail a few times, and plugged back in. The timer came back around and up came the newest content, no problem. This was exactly what I needed!

Now, for the usability side, I stole a few ideas I found scattered around online (I don’t have the links). Each time the function holding my Ajax call is run, I create two variable holding setTimeouts. onSuccess of the Ajax call, I wipe the timers out, but if they make it all the way to the end, they display messages. The first timer, at 60 seconds, tells the user that we’re having trouble talking to the database, but there’s no need to panic just yet. The second timer, at 120 seconds, suggests that it might be a good time to check the network connection and maybe call the system administrator (Fortunately that’s not me. She does have my number though, and isn’t afraid to call it at any hour).