next »

[perkiset]

LOL that's been the largest issue with this problem from the start it seems... completely unreliable. I have yet to be able to *reliably* reproduce it at will... I have to run dozens or even hundreds of tests before I get something good enough to call a pattern.

That's very interesting about the POST and it happening on other requests as well... I'll look forward to hearing your results.

/p

[perkiset]

Doesn't using HTTP 1.0 yield no host headers?  If I recall, it does not.

May need to account for the lack of a host header if you are doing any virtual domain hosting or re-writing based on host/domain name.

Right you are SB - that was one of the biggest advantages to 1.1 and arguably the reason for it's quick and ubiquitous implementation... that'd be a complete showstopper for me.

[perkiset]

Everything is sub-domained at Google for the most part. 

Regarding cross-domain Ajax queries: SB I'm going to be starting a new thread today or tomorrow specifically on this issue. Have done a WHOLE bunch of research lately and will be sharing - it's at once maddening, saddening and finally gladdening (jeez was that hokey)...

Stay tuned!
/p

[kidplug]

Well my theory was partially shot down.

I just produced a 12152 error in the browser on an ajax post, and NOTHING was logged on the server...
So apparently that error is not the cause of my server-side exceptions.

However, I also just produced a timeout in the browser on the same ajax post - timeout is set to 7 seconds in my ajax code.
My ajax code automatically retried, and when it did, I got TWO requests logged on my server.  The first one appears to be the "bad" one which caused a timeout in my client code, and will probably produce the "short read" exception in tomcat in a few minutes.

The second request was handled fine and returned a response to the browser.

Oh - There's the exception - exactly five minutes have passed now.

The thing is - my ajax retry after timeout DOES call abort() before retrying.
It seems that in this case the abort() actually resulted in my server getting the "bad" request.
Again, my server didnt log anything on the first request that timed out, until abort() was called in the client.

In summary, it looks like my server side errors are the result of client-side ajax "timeouts" which are retried.
I am already calling abort() on the failed (timed out) xhr requests, so I dont know what else to do to prevent the server side issue.

Hopefully IE7 fixes this, as is claimed...

[perkiset]

On a different tack -

As I hinted to SB above, I'm going to start a new thread on XHR alternatives either later today or tomorrow, based on a boatload of recent research. I am enormously frustrated with XHR in IE, and also have a need for cross-domain stuff, so I have pretty much wrapped up a new solution for myself.

I don't know if it will assist with what you've got going, but it might turn some gears...

/p

[kidplug]

This may be getting off topic, since I'm talking about the timeout issue, not the 12030 issue, but I've found an interesting pattern.

The timeout is occurring on a subsequent ajax post in the time window of 16 seconds to 60 seconds.

Meaning, if the last request was within the previous 15 seconds, there is no problem.
Or if the last request was over 60 seconds ago, there is no problem.

But in the 16-60 second window, the subsequent request is timing out for me EVERY time.
Funny I hadn't noticed that before.

I haven't tried it yet with a regular POST from a form.
Again, this is IE6 over SSL and seems to be related to the keep-alive issue.

---
And thanks - I will check out your alternative solution(s).

[perkiset]

 

Are you saying that if you throw another request at exactly 15 seconds it will fly, but at 16-60 seconds it will bomb RELIABLY? That is astonishing if I'm reading you correctly... if that's the case, then the next thing to test is, is that time frame specific to <your machine> or is that systemic... ?

Also - I just reread your post and noticed something - as you note, I am also doing a setTimeout'd retry... but the solution that I found was to separate the open() from the send() by 10ms IF the browser is IE... essentially, let any resources get up-to-date (because I've allowed the message loop to spin, I presume) before the send is dispatched. Here is that code fragment as it's laid out in my requestor:

Code:

var loader = this;
this.requestor.onreadystatechange = function() { loader.__onRTS.call(loader); }
if (this.masterStatus) { this.masterStatus.handleChange(true); }

// Set a callback to <me> in case the request takes to long...
this.timeoutHandle = setTimeout( function() { loader.__handleTimeout.call(loader); }, this.timeoutMS);

this.requestor.open('POST', theURL, true);
this.requestor.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
  if ((document.all) && (document.getElementById))
  {
  // IE
  setTimeout( function() { loader.__executeSend.call(loader)} , 10);
  } else {
this.requestor.send(this.__postParams());
}
}
ajaxRequestor.prototype.__executeSend = function() { this.requestor.send(this.__postParams()); }

I think that this might help you out - it is the only thing that I found that reliably stopped the issue.
Important note: The last version of the posted code in the repository did not contain this patch - the second to the last did... the last post has been updated.

/p

[kidplug]

Hmm - I will try the timeout between open() and send().  I am not doing that now.

Yes you are reading correctly - from my browser - IE6 on XP, the 16 - 60 seconds is very repeatable.
When I throw in a GET request in there it changes things a bit, and if a 12030 or 12152 occurs it also changes a bit.
After one of those errors, subsequent requests > 16 seconds throw an additional 12030 - not sure how consistent this is...

But after a successful POST, a second POST in that timeframe is timing out on me every time.

I did notice something that may be useful.
During these timeout periods, the readystate is 1.
On other requests which are taking some time, due to large amount of data being returned, or intensive operation on the server, the ready state is 3 during my timeout counter.

So maybe if I detect a ready state of 1 after even 1 second, I can just abort and retry.
Better than waiting the full 7 seconds, or whatever timeout I have specified.
In fact if I am aborting these readystate==1 requests after 1 second, I can set a higher allowable timeout for requests that are actually succeeding, but just taking a while.

I'm sure I will still get these phantom requests on my server if I abort after 1 second.

[kidplug]

I added a setTimeout between open() and send() but that doesnt seem to change the behavior.

Are you only doing that in your retry? Or also on the initial send() ?

My retry is pretty much 100% successful as it is.


I did add the abort() after one second on readystate==1 which I think will improve user experience.
It still sends the double request back to the server though.

[perkiset]

I added a setTimeout between open() and send() but that doesnt seem to change the behavior.

Are you only doing that in your retry? Or also on the initial send() ?

My initial send - if the browser is IE, then I DONT send in the same function as the open() - I set up a timeout to execute the send 10ms later

/p

[kidplug]

This is definitely pertinent:  my apache config file specifies KeepAliveTimeout 15.

That must be where the 16 seconds is coming from.

[perkiset]

  yep, that'd definitely be the case... thanks for that update - I'da pulled my hair out looking for that one

[kidplug]

So the errors and timeouts are clearly caused by the xhr trying to use an https connection which the server is no longer maintaining.

Good news - not happenning on IE7 on the machines that I've tested.

I still hate having those server-side errors after the failed/timed out xhr requests.

Have you or others observed this timeout issue at all?
I wonder what the Keep Alive timeout is on your web server(s).

Thanks.

[perkiset]

OK:

My older framework (apache proxies through to Object Pascal renderers in a reverse-proxy/firewall setup: both the front end and back end boxes have the timeout on and set to 15 - this would be the default way that they were installed I assume. Neither of them have any AJAX running through them - I only tell you this because it seems to be a default way that Apache installs.

My newer frameworks go through an instance of IPCop and then on to an instance of Apache 2 that does NOT have a keepalive directive in it... so I assume that it will use default values - I don't know what those are - have to go research that, although I'm thinking that with no directive, KeepAlive would be OFF by default... interesting...

/p

[StephenBauer]

Everything is sub-domained at Google for the most part. 

Regarding cross-domain Ajax queries: SB I'm going to be starting a new thread today or tomorrow specifically on this issue. Have done a WHOLE bunch of research lately and will be sharing - it's at once maddening, saddening and finally gladdening (jeez was that hokey)...

Stay tuned!
/p

Looking forward to it...

SB