views:

363

answers:

2

I am trying to use jQuery's .ajax functionality to make a progress bar.

A request is submited via .ajax, which starts a long running process. Once submited another .ajax request is called on an interval which checks the progress of this process. Then a progress meter is updated using this information.

However, the progress .ajax call only returns once the long running process has completed. Its like its being blocked by the initial request.

The weird thing is this process works fine on dev but is failing on the deployment server. I am running on IIS using ASP.Net MVC.

Update: Apparently, it is browser related because it is working fine on IE 7 but is not working on IE 8. This is strange because IE 8 allows up to 6 connections on broadband where IE 7 only allows 2 requests per domain.

Update2: I think it's a local issue because it appears to be working fine on another IE 8 machine.

+1  A: 

Some browsers (in particular, IE) only allows two requests to the same domain at the same time. If there are any other requests happening at the same time, then you might run into this limitation. One way around it is to have a few different aliases for the domain (some sites use "www1.example.com" and "www2.example.com", etc)

You should be able to use Firebug or Fiddler to determine how many requests are in progress, etc.

Dean Harding
Just further to this, another way that I've used in the past is that the first request will spin up a whole new thread on the server to process the request "in the background" so that the first Ajax request returns straight away. Then you can use subsequent requests to return the progress. This is a bit (lot) more work, but it doesn't tie up a server connection for long periods of time.
Dean Harding
+1  A: 

The server will only run one page at a time from each user. When you send the requests to get the progress status, they will be queued.

The solution is to make the page that returns the status sessionless, using EnableSessionState="false" in the @Page directive. That way it's not associated with any user, so the request isn't queued.

This of course means that you can't use session state to communicate the progress state from the thread running the process to the thread getting the status. You have to use a different way of keeping track of running processes and send some identifier along with the requests that gets the status so that you know which user it came from.

Guffa