next »

[perkiset]

Well, I can only frustrate I'm afraid.

I built some automated systems that pulled against my SSL Ajax systems . I tried different versions of Windows, different processor loads, faster and slower connections, multiple instances of IE open at the same time, being the first thing done and clicking after a session had been open for a long time.

Same randomness, no matter what.

The worst part, was that I'd go, like, 3000 iterations with nothing and think I was on to something, and then POOF it'd be back.

That's why I write the XHR I referenced earlier - I needed a way to securely send data to an AJAX app.

My most recent retail stuff is using more JS, then POSTs and finally an iFrame for the moment of truth. Works like this: I do almost all verification of data via JS on the local client. When I like it there, I POST it up to the server (checking again, of course) but pushing everything into a session so that it's usable. (This part may be done several times, based on what the client system needs to do). When I actually initiate a transaction, I use a hidden iFrame so that I can continue with a local animation (to let the client know something's going on) which returns a small script to bounce the client when a transaction is complete or not.

I use AJAX for anything that is unsecure, or backoffice systems where I can control which browser is used. It's perfect - fast and accurate - if I can control the browser.

[brouleau]

!Alleluhia! Lord oh! Lord save us all... I found something that makes so much sens that it is scary:

I do not know about you guys, but for us, since we have High traffic and to protect against some traffic intensive part of our application using up all the bandwidth, at some point last year we installed NetLimiter. Be careful when reading this bit, as I am not accusing NetLimiter of doing anything wrong. But since it is designed to limit the NET traffic, well that is just what it does, therefore slowing down random connections when traffic hits the high point where it needs to be toned down. Those connections then timing out. Of course this sort of application is not the only one that can get you to reproduce this problem, hitting your ISP high traffic limit, your ISP probably does just the same without you knowing about it.
Apparently IE is easier to timeout than any other browser and this is why switching browser makes the problem almost disappear, but make no mistakes this still happens with other browser, I have encountered a few posting with firefox.
So I am ready to bet that you (perkiset and Dragonlaird more specifically) have some means to limit the NET traffic on your server. This is even worst to debug as most of us are using internal connection to our web site. Since the internal traffic does not get limited because not using bandwidth, this means that internally we do not see this error, making it virtually impossible to debug reliably.

Any ways, since we reconfigured NetLimiter to limit the traffic in general but allowed jsp traffic to go through undisturbed (which represent 98% of our application), we do not see this error anymore. Suffice to say that we have a kick ass connection and not that many users. We were limiting the traffic to keep the ISP invoice as low as possible since they allow us to use as much bandwidth as we may, but they sample it and charge a super high fee if we exceed a certain limit more than 5% of the time.

Please let me know if this makes sense, if this help you or if this is of no relevance whatsoever.

Cheers,

A happy brouleau