Intermittent Ajax issue

Posted in xn--kfs74mzzid01b.com edit by rose on January 7th, 2009

Hi there. I have an intermittent problem with my ajax calls that is proving difficult to debug. I'm not sure if it is a problem on the server or client side, so I'll explain what I'm seeing and maybe someone can offer a pointer.

About every 1 in 50 ajax calls I am apparently not receiving a response from the server. Firebug just displays "Loading...". I have examined my apache server logs and as far as apache is concerned the response is a code 200 and data is being returned - data exactly the same size as that of a "successful" call.

I have attached a screenshot of the firebug console showing a non-responsive ajax call, followed immediately by a call to the same url that is working correctly.

The ajax calls in question are using the Ext updatemanager. Is there any setting in this that could possibly be causing this error? I have added this as per the recommendation found elsewhere on this forum:
Ext.Ajax.on('beforerequest', function(ajax, o){ o.autoAbort = false; });

I am using Ext 1.1 beta, and the issue is occurring both on my Windows dev box and my Linux live box.

Cheers,

Chris

I was wondering if anyone else was having this issue. I still have it happen, and I know it's not ext. I know that when I send the request to the server, it gets processed by the server. It's just that my response has intermittently been coming back as "undefined". At this point, I'm unsure how to track this down. Any help determining how to track this issue down would be helpful. I'm using Apache and Perl to process my data.

Is it possible the browser is timing the requests out internally? The is a 2 connection limit, and I know in most cases requests are executed in sequence.

There is no guarantee from the browser that it will run AJAX calls in sequence.

The responseText returns 'undefined'.

Disable Firebug and all other extensions and see if it continues.

Also, use IE + Fiddler. Since Fiddler is working (technically) as a proxy, it won't interfere with the processing of a request like Firebug can. Firebug is great, but it does have a number of bugs (make sure you have the latest, btw).

[BTW: I've seen the bug you describe before ever using Ext...]

Is it possible the browser is timing the requests out internally? The is a 2 connection limit, and I know in most cases requests are executed in sequence.

Don't use the "Net" tab in firebug to watch Ajax calls. It is buggy... as you have seen. Instead switch to the console tab and in the "options" menu select showXMLHTTPRequests. It gives you the same information but it actually works. (100% of the time)

I am quite sure this issue is due to the buggy "Net" tab in firebug. It has caused me a lot of pain before I discovered the console workaround.

Like I mentioned before... do not use the Ajax tab. It doesn't work. Occasionally when you try to view your request it will actually resend the request with no parameters which is probably what is causing your error. Use the console to view your ajax requests... it always works.

I'm not using the ajax tab, I'm using the console.

This is just basic usage, and has nothing to do with Ext really. If you are running torrents, or your DNS server farts on the request, you are up SC w/o a paddle. It's important to make use of Ext's callbacks to ensure that stuff actually gets done. The Ext callback is your only recourse to achieving failsafe operation.

For example, with code like this:

// code block A

var tsCategoryStore = new Ext.data.JsonStore({
url: proxyURL,
baseParams: { action: "ticket_categories" },
fields: [ 'id', 'label', 'css', 'enabled', 'accessible' ],
method: "post",
headers: { 'Accept' : 'application/json' }
});
tsCategoryStore.load(); // may die

// code block B

replace it to something like

// code block A

var tsCategoryStore = new Ext.data.JsonStore({
url: proxyURL,
baseParams: { action: "ticket_categories" },
fields: [ 'id', 'label', 'css', 'enabled', 'accessible' ],
method: "post",
headers: { 'Accept' : 'application/json' }
});
loadthestore( tsCategoryStore ); // below

}

....

function loadthestore( s ){
s.load({
function( oElement, bSuccess, oResponse ){
if( bSuccess ){
// code block B moved here
}
}
else{
loadthestore( s );
}
}
});
}

Firebug returns nothing when the server response exceeds timeout. Loading... is all you get. Most if not all Ext gizmos have such a callback available.

Cheers.
Alex

Upon further inspection it appears the request may not be even reaching the server... could the problem be something do with what is described in this thread:http://extjs.com/forum/showthread.php?t=9831?

Okay sorry to reopen this again, but I've done some more digging. Domitian it looks like our issues are separate - my server IS returning 200.

Looking at my access.log file for apache, here are two sequential ajax requests for the same URI - the first one succeeds (client-side), while the second one fails:

127.0.0.1 - - [22/Aug/2007:11:32:06 +1200] "POST /jm2/orders/add HTTP/1.1" 200 7866
127.0.0.1 - - [22/Aug/2007:11:32:13 +1200] "POST /jm2/orders/add HTTP/1.1" 200 7866

So both requests are successful (200) and return data (7866 bytes).

In this case the second request did not "make it" to the browser somehow, so FireBug (and Ext) just displays "Loading...". Using the HTTP Live Headers extension I can see that no response headers are being received.

The request isn't timing out, the server is processing it immediately.

What would be my next step in debugging this? It's as if the XMLHttpRequest object is sometimes not "seeing" the response to the POST.

Chris

I actually have this same issue. And my server is on the same machine as my dev box. It seems to happen more than I expected.

Disable firebug and use fresh extention-free Firefox and an HTTP sniffer (or IE and a sniffer). I've seen this bug in the Net tab AND the Console in Firebug. I can't remember how I fixed it, or what the source problem was, but I'll remember eventually...

cdomigan, I think you looking in the wrong direction. I would be very surprised if it was an issue in the request code, as that is being usedby thousands of people for POSTs and GETs without issue.

What you are describing is a request that the server returns nothing. If the request is complete but the server doesn't return anything, in FireBug it will forever display loading.

This would explain the problem I'm seeing. My transactions never make it to the server. Jack is the fix provided in the link something that we could do?

I am seeing this problem mainly on one-off ajax calls - ie I'm not making a number of calls simultaneously.

Going by my screen shot in the initial post, you can see that the first ajax request has "completed" - with a 375ms round-trip time. However no headers are returned and Firebug simply displays "Loading...". I guess I'm wondering what this means - obviously as far as the browser is concerned the ajax connection is now closed, just no response was received. But then if no response was received why has it aborted/timed out after only 375ms? Unless it is not correctly POSTing the request in the first place.... round in circles we go :(

Confusing.

The error for me seems to occur more frequently with my requests that are autoRefreshing. It also occurs when I'm doing a bulk requests (i.e. initializing 8 local data store when logging into my application). Although it has been known to occur on single requests. It seems rather inconsistent as far as bugs go. I'm not sure what's triggering it.

Have you guys tried any kind of logging on the server side? Without knowing your setups it's hard to guess what might be failing, but it could be that you're actually getting some error somewhere (Perl, Apache, DB, app code, ...) that's getting swallowed or handled improperly. If you could at least eliminate the other potential error points on the server side and guarantee that the server application code is actually exiting as expected when the issue occurs, that would at least eliminate some suspects.

@Domitian: When you say the response is "undefined" what do you mean? That the actual HTTP response string is "undefined" or that the JS responseText property is undefined, or what?

Actually that's a poor assumption. For my scenario, 200 isn't coming back. It's something else, because I throw up a prompt when it's a response other than 200. My 'undefined' term is coming back in that prompt. I've reasoned it out that it has to be either Apache or Perl that's messing up. I'm inclined to think it may be Perl. Maybe a configuration issue with concurrent threads or requests? I'm just speculating...

If it's never reaching the server, it wouldn't have anything to do with that thread. The problem outlined in that thread is not really an issue, although for consistency, it really should clear the timeout.

How frequently are you polling the server?

There's not much I can suggest. I would imagine sometimes a request can can fail at some point. That request will timeout, and you can re-issue it?

Yeah this is still a real show-stopper for my project at the moment. I'm trying to get my head around the life-cycle of a xmlhttprequest so that I can try to understand what might be happening. As I understand it, if the Ajax call completes and Firebug still displays "Loading..." that means that no data was received from the server. I assume though that an 200 OK *must* have been received for the call to complete successfully?

One more thing... add something to the URL of the request such that NOBODY is using cache somewhere... (and this does lead into some Firebug bugs).

Hey Alex, I appreciate the response. I agree that it probably is the server losing the response packet; the only thing that I want to note is that it's not timing out. It just responds instantaneously. For example the loading message occurs within milliseconds of my request being sent out. I understand it could just be my server, so I was wondering if anyone else had noticed this sort of behavior on their box? Is there anyway to mitigate it from happening too often?

#If you have any other info about this subject , Please add it free.#

Intermittent Ajax issue

Archives

Meta