Strange jQuery/Apache Lockup

[Tetsujin]

Hi people,

I'm having a very strange old time with a little bit of jQuery/php combo, and I'm not sure where the problem lies. The order of events that takes place is:

1. index.php sends some html to the browser, including some "launch" js
2. this launch code sends an XMLHTTPRequest to a php script, telling it to start scanning a site (this scan takes a long while so this php script doesn't return anything for at least 40 seconds)
3. this scan process starts inserting records into my database, so that then:
3. as the above is done asynchronously, i then, from the same js code, ask the same php script for a different function - a status update of what's gone into the database so far
4. in theory this should respond instantly and i can have a nicely "real time" updating counter back on the original html page

I hope I've explained that well. Essentially I need to scan 100+ pages of a website for certain info (scraping, if you will, although this isn't nefarious) but don't wish to leave the browser sat there for 40+ seconds, so I trigger the php scan script via ajax, then immediately use setTimeout to call a "give me an update" php script.

However this step of asking the php script for an update doesn't return anything at all until the first scanner script has finished, some 40+ seconds down the line. The JS is definitely sending both requests, but the webserver doesn't even invoke the index.php script for the "give me an update" until after the scanner is done.

This sounds like a webserver configuration issue to me, but I'm at a loss. I can access other php scripts on the webserver just fine, but seemingly not this index.php I'm passing all these (well, these two) requests through. Is there some limit in apache with how many concurrent instances of a single script it can have open or something? It's really doing my nut in.

 

[suarve]

Have you tried loading up Firebug while the page is loading? It's a lifesaver for things like this as you can see things like AJAX requests happen in front of you

 

[Tetsujin]

Yeah, I have, and Firebug shows the two XMLHTTPRequests as being fired off... however after some more tinkering the new hypothesis is that for some reason the browser's actually only sending off the first one, despite it being apparently asynchronous, and although firebug lists the second request i don't think it's actually being sent until the response to the first one comes back.

This makes a lot more sense than the request somehow being queued at the server side of things, especially as manually making the request in another browser works fine. So I'm basically blaming jQuery and going to try some alternate xmlhttprequest wrappers.

Fingers crossed!

 

[Goofball]

You could check with Fiddler if the requests are actually fired, I belieave they should be fired asynchronously by jQuery (both fired imidiately).

It might be that your web server configuration doesn't allow multiple requests on the same session?

That's how it is with IIS/.NET at least. The client can send multiple requests, but their all serialized server side to avoid race conditions on the session and context objects. So a big slow request will block everything else from the same session until it's done.

Looks like that's exactly what you're experiencing. It fits with firing the request manually from another browser as well (different session).

 

[Tetsujin]

Hrm good idea Goofball, that's something to check out. I don't think Apache works in the same way, and the second script request isn't even being passed to PHP so I don't *think* it's anything to do with sessions as they won't exist at that stage, but something to look into. Thanks!

 

[Tetsujin]

Ok so Fiddler is my new best friend, thanks so much for that. It being external to FF I *know* that FF is definitely sending the requests now, so it must be the webserver queueing them up for some reason.

Not sure how I can bypass this (tried using separate files for each function, on the off chance, but same result), I'm guessing I might have to trigger the scan process itself as a commandline script from the call where 'action=scan' or something, so that it can return to the browser and the 'action=status' one can be processed by the webserver. Hrmm...