Subject: setTimeout, xmlHTTP, file posts
Posted By: wax Post Date: 12/7/2005 12:23:29 PM
Hi,

Thanks in advance for any time spent on this.

What am I trying to do?
I'm trying to create a AJAX powered progressbar for a simple file upload script.

How am I trying to do it?
I have a form with a file field, and a submit button, and some some Javascript.
As soon as the form gets submitted Javascript gets executed to do a request to another page which retrieves the progress of the file upload (number of bytes of the file written to file so far) and returns it.

This javascript also uses 'window.setTimeout' to call this function every 3 seconds to update its progress throughout the file upload.

The initial request (which gets fired straight off from the submit button) gets called, and executed just fine. Repeated calls (which should be called via the setTimeout bit) however, do not.

When I hit the stop button on my browser (effectively canceling the file upload) the calls from the setTimeout do get called.

So I guess my question is:
1. Does a filepost 'block' xmlHTTP ?
2. If so, how could I go about doing this then ?
3. I am basing my script loosely on `http://encodable.com/tech/ajaxupload/ajaxupload.txt` which from my limited perl knowledge I have mimiced fairly well in terms of how to go about doing a progressbar for a upload. This script does not seem to be bothered by calls being blocked because of a filepost being in progress..

 Thanks..


Reply By: planoie Reply Date: 12/12/2005 4:12:55 PM
Once you hit a form post action (like the submit button), the browser will very likely "lock up" until it starts receiving a response from the server.  I don't know if there's any way to avoid this.  

I have notice a slight difference in behavior between my work computer and my home computer when running AJAX type of actions.  My home machine which is running a slightly newer version of MSIE updates graphics and such while an AJAX call is in progress while my work machine doesn't.  This might be due to any of three major factors:
1. Home machine is newer version of MSIE
2. Home machine is connected via VPN and thus a slower network connection (maybe the network lag is enough for the browser to do what it needs before the AJAX response shows up)
3. When at home I'm 'talking' to my development machine at work via the network, where-as at work, I'm 'talking' directly to the same machine.  Maybe the fact that when I'm at work the same machine is doing everything: making the request and serving the response.  However, I have seen the same behavior from another work machine (which is running a similar version of I.E.).

Despite all this babble, I suspect that the most likely cause of this problem is that the form post is stopping all other browser activity including those timeout calls.

-Peter
Reply By: wax Reply Date: 12/12/2005 6:59:48 PM
quote:
Originally posted by planoie

Once you hit a form post action (like the submit button), the browser will very likely "lock up" until it starts receiving a response from the server.  I don't know if there's any way to avoid this.  

I have notice a slight difference in behavior between my work computer and my home computer when running AJAX type of actions.  My home machine which is running a slightly newer version of MSIE updates graphics and such while an AJAX call is in progress while my work machine doesn't.  This might be due to any of three major factors:
1. Home machine is newer version of MSIE
2. Home machine is connected via VPN and thus a slower network connection (maybe the network lag is enough for the browser to do what it needs before the AJAX response shows up)
3. When at home I'm 'talking' to my development machine at work via the network, where-as at work, I'm 'talking' directly to the same machine.  Maybe the fact that when I'm at work the same machine is doing everything: making the request and serving the response.  However, I have seen the same behavior from another work machine (which is running a similar version of I.E.).

Despite all this babble, I suspect that the most likely cause of this problem is that the form post is stopping all other browser activity including those timeout calls.

-Peter


Thank you Peter, that sounds like what I suspected, but that leaves me with the problem still. Do you have any suggestion in regards to this ?

I've seen asynchronous http handlers mentioned here and there, would they have any sort of benefit to this type of action ?

 Thanks

Reply By: planoie Reply Date: 12/15/2005 10:51:46 AM
The core of the problem is that you are trying to do 1 simple action.  When you do a file post thru a standard HTML form, the post simply includes the binary stream of the file in the post data.  Thus, the time delay is just the time it takes for the complete HTTP POST to be sent up to the server.  When you have a large file in that data it will just plain take a while.  In order to provide a better user experience you might need to look into building something that runs on the client side that provides better feedback.  I've seen examples of such things on sites like Kodak's Ofoto.  You can do "bulk uploads" of pictures.  The page runs some kind of applet (java or activeX) in the browser that handles the upload.  It provides good status data with progress bars and all.  I've never build such things so I can't provide more that this suggestion.

-Peter
Reply By: UncaDanno Reply Date: 1/11/2006 8:53:24 AM
Wax,
Let's take a look at a progress line, if you will.
Here is what you want:
Submit upload.....prog update....prog update...prog update....End upload.

Here is what is probably happening:
Submit upload....end upload....callback checks status.

Even though you probably tried to decouple the progress updates by putting them in a separate page, that page is on the same server as your upload page.
Remember, IIS relies on your session ID to make the call back to the callback routine on your browser.
ASP processing is single-threaded. This means that the call from your session to the progress update page has to wait until the call from your session to the file upload process.

Go to topic 37322

Return to index page 398
Return to index page 397
Return to index page 396
Return to index page 395
Return to index page 394
Return to index page 393
Return to index page 392
Return to index page 391
Return to index page 390
Return to index page 389