By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,948 Members | 1,559 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,948 IT Pros & Developers. It's quick & easy.

AJAX request hangs for 5 minutes

P: n/a
My site uses lots of AJAX requests to PHP files which then retrieves
data from MySQL. About 95% of the time the requests complete without
issues. Every once in a while a request will hang for exactly 5
minutes then fail. It seems to be occuring on the client side. I
can't re-create the issue. It just happens randomly. I think it
eventally reaches the server (Apache) because I can see errors in the
server log that certain POST/GET variables are undefined. The
variables are clearly defined. One thing it could be is that it's
only tied to POST requests since I read somewhere that POST makes two
requests to the server. I have this issue with IE6 and IE7 and could
be tied to the wininet.dll I briefly read about as well. I'm not
sure. Below is the typical structure I use for my requests. Any help
will be appreciated. Thanks...

function loginReq(frm){
var req=false;
var msg=document.getElementById("msg");
msg.innerHTML="";
msg.className="error";
if(window.XMLHttpRequest){
req=new XMLHttpRequest();
}else if(window.ActiveXObject){
try{req=new ActiveXObject("Msxml2.XMLHTTP");}catch(e){
try{req=new ActiveXObject("Microsoft.XMLHTTP");}catch(e){}}
}
if(!req){
msg.innerHTML="There was a problem with the request!";
return false;
}
req.onreadystatechange=function(){
if(req.readyState==4){
if(req.status==200){
if(req.responseText.substr(0,1)=='<'){
document.getElementById("main").innerHTML=req.resp onseText;
}else{
msg.innerHTML=req.responseText;
}
}else{
msg.innerHTML="There was a problem with the request!";
}
}
}
var prm='user='+frm.user.value+'&passwd='+frm.passwd.v alue;
req.open('POST','login.php',true);
req.setRequestHeader("Content-type","application/x-www-form-
urlencoded");
req.setRequestHeader("Content-length",prm.length);
req.setRequestHeader("Connection","close");
req.send(prm);
}
Sep 12 '08 #1
Share this Question
Share on Google+
10 Replies


P: n/a
mo*****@yahoo.com wrote:
My site uses lots of AJAX requests to PHP files which then retrieves
data from MySQL. About 95% of the time the requests complete without
issues. Every once in a while a request will hang for exactly 5
minutes then fail. It seems to be occuring on the client side. I
can't re-create the issue. It just happens randomly.
Reads like a race condition.
I think it eventally reaches the server (Apache) because I can see errors
in the server log that certain POST/GET variables are undefined. The
variables are clearly defined. One thing it could be is that it's
only tied to POST requests since I read somewhere that POST makes two
requests to the server.
Either you have read utter nonsense or misunderstood completely what you had
read. One (POST) request is still *one* (POST) request.
I have this issue with IE6 and IE7 and could be tied to the wininet.dll
I briefly read about as well. I'm not sure.
Wouldn't other UAs running on Windows have to use wininet.dll as well?

<http://msdn.microsoft.com/en-us/library/aa385483.aspx>
Below is the typical structure I use for my requests. Any help will
be appreciated. Thanks...

function loginReq(frm){
[...]
if(window.XMLHttpRequest){
^^^^^^^^^^^^^^^^^^^^^
req=new XMLHttpRequest();
}else if(window.ActiveXObject){
^^^^^^^^^^^^^^^^^^^^
Those are hardly sufficient feature tests. For example, not every property
can be called. And you should not rely on the `window' property to refer to
the Global Object. Read the FAQ and search the archives on both.
try{req=new ActiveXObject("Msxml2.XMLHTTP");}catch(e){
try{req=new ActiveXObject("Microsoft.XMLHTTP");}catch(e){}}
}
Testing for `Microsoft.XMLHTTP' usually suffices.
if(!req){
msg.innerHTML="There was a problem with the request!";
return false;
}
req.onreadystatechange=function(){
[...]
}
var prm='user='+frm.user.value+'&passwd='+frm.passwd.v alue;
If you declare `Content-type: application/x-www-form-urlencoded', you MUST
escape the values that you use as an URI component or in the message body,
using the percent encoding defined in RFC3986. Implementations of
ECMAScript Ed. 3 provide the encodeURIComponent() method for that purpose;
for older implementations you need escape() and maybe even a dummy method as
fallbacks.
req.open('POST','login.php',true);
That call must come *before* you assign to the `onreadystatechange' property.
req.setRequestHeader("Content-type","application/x-www-form-
urlencoded");
This call is not universally supported, you need to feature-test it and
catch the exceptions it may throw. It is likely to be superfluous anyway.
req.setRequestHeader("Content-length",prm.length);
req.setRequestHeader("Connection","close");
These calls are pointless, the implementation will likely ignore them.
req.send(prm);
}

HTH

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Sep 13 '08 #2

P: n/a
function loginReq(frm){
[...]
* if(window.XMLHttpRequest){

* * * *^^^^^^^^^^^^^^^^^^^^^* * req=new XMLHttpRequest();
* }else if(window.ActiveXObject){

* * * * * * *^^^^^^^^^^^^^^^^^^^^
Those are hardly sufficient feature tests. *For example, not every property
can be called. *And you should not rely on the `window' property to refer to
the Global Object. *Read the FAQ and search the archives on both.
If you are referring to < http://www.jibbering.com/faq/ >, I couldn't
find anything which tells us not to rely on the 'window' property to
refer to Global Object. Correct me if I am wrong but if the test for
the Global XMLHttpRequest property is successful, we can be almost
always sure that it will be a function.
* req.open('POST','login.php',true);

That call must come *before* you assign to the `onreadystatechange' property.
The working draft of XMLHttpRequest says it comes after you assign the
onreadystatechange property.
< http://www.w3.org/TR/XMLHttpRequest/ >
* req.setRequestHeader("Content-type","application/x-www-form-
urlencoded");

This call is not universally supported, you need to feature-test it and
catch the exceptions it may throw. *It is likely to be superfluous anyway.
Though XMLHttpRequest is still not standardized, doesn't each and
every implementation out there provide a setRequestHeader function?
>
* req.setRequestHeader("Content-length",prm.length);
* req.setRequestHeader("Connection","close");

These calls are pointless, the implementation will likely ignore them.
The default 'Connection' request header used by the browser when
issuing HTTP Requests is 'Keep-Alive' so if the XHR implementation /
HTTP Client chooses to ignore the one which overrides the default,
wouldn't it be kind of wrong?
Sep 14 '08 #3

P: n/a
On Sep 14, 2:15*pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
sasuke wrote:
The default 'Connection' request header used by the browser when
issuing HTTP Requests is 'Keep-Alive'

Nonsense. *Obviously you have no idea what you are talking about. *Read
RFCs 1945 and 2616, and please don't continue here before you did.
I guess not on each and every browser out there but at least FF works
this way. Trapping the Request headers with a sniffing tool says so at
least. But you are right, it's not a mandate.
so if the XHR implementation / HTTP Client chooses to ignore the
one which overrides the default, wouldn't it be kind of wrong?

Non sequitur. *Why don't you simply test my advice? *BTDT.

One wonders why you asked here if you think you know everything better.
Kindly point me a passage from my previous post which indicates my
claiming to know everything. I know you know better than me hence
those questions were not 'question tags' but genuine 'queries'.
Apologies to everyone for hijacking the thread; was curious. Still,
anyways, thanks for the clarifications.

Regards,
/sasuke.
Sep 14 '08 #4

P: n/a
sasuke wrote:
Thomas 'PointedEars' Lahn wrote:
>sasuke wrote:
>>The default 'Connection' request header used by the browser when
issuing HTTP Requests is 'Keep-Alive'
Nonsense. Obviously you have no idea what you are talking about. Read
RFCs 1945 and 2616, and please don't continue here before you did.
I guess not on each and every browser out there but at least FF works
this way. Trapping the Request headers with a sniffing tool says so at
least. [...]
That depends on the HTTP version negotiated with a proxy or server, and the
capabilities of the proxy or server. Did I or did I not suggest you read
the Specifications, where this is explained, before you posted here again?
>>so if the XHR implementation / HTTP Client chooses to ignore the
one which overrides the default, wouldn't it be kind of wrong?
Non sequitur. Why don't you simply test my advice? BTDT.

One wonders why you asked here if you think you know everything better.
Kindly point me a passage from my previous post which indicates my
claiming to know everything.
I can point you to your whole posting where you question every statement
that I made. Granted, it appears as if one of your statements eventually
improved (my) knowledge about XHR slightly.
I know you know better than me hence those questions were not 'question tags'
but genuine 'queries'.
Bluntly questioning things that had already been explained ad nauseam
before, and immediately after they have been explained again, without making
any appearance of having done any double-checking, can be easily perceived
as a wannabe's know-everything-better attitude. That does not mean at all
that questions should not be asked, though. But please ask smart questions.

<http://catb.org/~esr/faqs/smart-questions.html>
Apologies to everyone for hijacking the thread; was curious.
Don't be sorry for *this*. (There is no "hijacking" in this discussion
medium. An OP does not own a thread; threads can drift and should as long
they are on-topic.)
Still, anyways, thanks for the clarifications.
You are welcome, I think.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Sep 14 '08 #5

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
<http://catb.org/~esr/faqs/smart-questions.html>
I can somehow understand that you would identify with the abandoned Red
Hat Primadonna ESR.

(for some of your problems,
<http://www.catb.org/jargon/html/W/wannabee.htmlmight help :)

Sep 14 '08 #6

P: n/a
I think it eventally reaches the server (Apache) because I can see
errors
in the server log that certain POST/GET variables are undefined. *The
variables are clearly defined. *One thing it could be is that it's
only tied to POST requests since I read somewhere that POST makes two
requests to the server.

Either you have read utter nonsense or misunderstood completely what you had
read. *One (POST) request is still *one* (POST) request.
Sorry, I shouldn't have said'two requests'. Here's what I was
refering to:
"The Yahoo! Mail team found that when using XMLHttpRequest, POST is
implemented in the browsers as a two-step process: sending the headers
first, then sending data. So it's best to use GET, which only takes
one TCP packet to send (unless you have a lot of cookies)."

You guys are way over my head. Thanks for your help.
Sep 15 '08 #7

P: n/a
mo*****@yahoo.com wrote:
>>I think it eventally reaches the server (Apache) because I can see
errors in the server log that certain POST/GET variables are undefined.
The variables are clearly defined. One thing it could be is that it's
only tied to POST requests since I read somewhere that POST makes two
requests to the server.
Either you have read utter nonsense or misunderstood completely what you had
read. One (POST) request is still *one* (POST) request.

Sorry, I shouldn't have said'two requests'. Here's what I was
refering to:
"The Yahoo! Mail team found that when using XMLHttpRequest, POST is
implemented in the browsers as a two-step process: sending the headers
first, then sending data. So it's best to use GET, which only takes
one TCP packet to send (unless you have a lot of cookies)."
It would appear that my former statement applies. The Yahoo! Mail team
obviously does not know how either HTTP or TCP works:

<http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol>
<http://en.wikipedia.org/wiki/Transmission_Control_Protocol>

The TCP *three-way* handshake is one of the first things you learn when
studying computer science. So the question is, given their apparent utter
incompetence, do you really want to trust these people with your data?

When trimming quotes, please do not remove the attribution lines for the
text that you leave there.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Sep 15 '08 #8

P: n/a
Thomas 'PointedEars' Lahn wrote:
mo*****@yahoo.com wrote:
>"The Yahoo! Mail team found that when using XMLHttpRequest, POST is
implemented in the browsers as a two-step process: sending the headers
first, then sending data. So it's best to use GET, which only takes
one TCP packet to send (unless you have a lot of cookies)."

It would appear that my former statement applies. The Yahoo! Mail team
obviously does not know how either HTTP or TCP works:
While that quotation is clearly a load of crap - there's no guarantee
that a GET request will be sent in a single TCP segment, for example -
the problem is not how many segments actually get sent (and so the
TCP three-way handshake is beside the point).

Applications present data to the stack. The stack determines how that
data is assembled into TCP segments. It's certainly possible that some
implementations of XHR present POST requests to the stack in pieces
(maybe specifically the request-line and headers in one piece, and the
content-body in another); and that will likely cause most TCP
implementations to usually send the request as two or more segments.

This is indeed undesirable; all associated outbound data should be
presented to the stack at once, whenever possible, to take advantage
of path MTU, reduce overhead, and avoid Nagle / Delayed ACK interaction.

But selecting an HTTP request type based on this possibility is
idiotic. It's a micro-optimization that is likely to have no
observable effect in most cases; Nagle will come into effect if both
segments are smaller than the MSS, but that's only a 200ms delay. And
GET and POST are not equivalent; they are used for different purposes,
so selecting one over the other based on performance is simply wrong.

If a POST request is not idempotent, then replacing it with a GET
request is a violation of the spec.
The TCP *three-way* handshake is one of the first things you learn when
studying computer science.
Nonsense. The three-way handshake, and TCP in general, have nothing to
do with computer science; and it's unlikely that most people studying
computing learn the details of TCP as "one of the first things".

And the three-way handshake is irrelevant here. The HTTP request
itself is not sent as part of the handshake, so a GET request smaller
than the MSS can indeed be sent "with a single TCP packet" (though it
may not be), as the Yahoos claimed, once the conversation is
established. Whether the conversation already exists is extraneous to
the question of how many segments ("packets") are involved in sending
a GET request.

The important point is that GET should be used for idempotent
(loosely, "read-only") requests, and POST for non-idempotent (loosely,
"read-write") requests. The OP should see RFC 2616 - not vapid advice
from random development blogs - for more information.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Sep 16 '08 #9

P: n/a
On 2008-09-16 16:38, Michael Wojcik wrote:
Thomas 'PointedEars' Lahn wrote:
>It would appear that my former statement applies. The Yahoo! Mail team
obviously does not know how either HTTP or TCP works:
...
It's a micro-optimization that is likely to have no
observable effect in most cases; Nagle will come into effect if both
segments are smaller than the MSS, but that's only a 200ms delay.
The Yahoo! Mail team could speed that up that by using:

navigator.setSockOpt(IPPROTO_TCP, TCP_NODELAY, 1);

I should send them a note.
- Conrad
Sep 16 '08 #10

P: n/a
Conrad Lender wrote:
On 2008-09-16 16:38, Michael Wojcik wrote:
>It's a micro-optimization that is likely to have no
observable effect in most cases; Nagle will come into effect if both
segments are smaller than the MSS, but that's only a 200ms delay.

The Yahoo! Mail team could speed that up that by using:

navigator.setSockOpt(IPPROTO_TCP, TCP_NODELAY, 1);
I see your flame bait and raise you a provocation.
I should send them a note.
Using GET, presumably.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Sep 17 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.