Why won't IIS process more than 1 request at a time?

[Guest]

I have client side code that uses xmlhttp to make an asyncronous call to the
server. This call really churns the server and can take a couple of minutes
to finish. I have found that while this long call is processing, I can not
make any more requests to the server from the same session. I found this
because if I have two completely separate instances of IE, they will not
block each other, but if I do a File/New to spawn a separate instance of IE
that shares session, they will block each other.

Is this expected behavior? Is there a setting in IIS or on my web site that
I can change to increase the number of requests a client can have at a time?

 

[Juan T. Llibre]

That sounds like a threading issue.

 

[Patrice]

IMO this is more the 2 connections limitation enforced by the browser.

Try :
http://support.microsoft.com/kb/282402/EN-US/

 

[jd]

I believe that the default SessionStateStoreProviderBase class locks
the session while it is in use. Take a look here:
http://tinyurl.com/gr3jh

I don't know if there's a way to disable this; if not, then you should
be able to substitute another provider which doesn't do locking. If
you do this, just remember that there's a reason for locking: you will
end up with a mess if multiple sessions use the same "slot".

-- jeff

 

[bruce barker \(sqlwork.com\)]

the browser enforces a connection limit of 2, which can be overridden by a
registery entry. but asp.net ony allows one concurrent request per session.

-- bruce (sqlwork.com)

 

[Guest]

I did the registy update, but that did not help. Is there really a one
request per session limit on asp.net? If so, that is definitely my problem.
Is there a way around this?

 

[Jeff Dillon]

Yes, don't do File/New? Why are you doing this in the first place?

Jeff

 

[Guest]

No, that was just a test that I did to prove that the issue is linked to the
session. I have a single page that uses asyncronous xmlhttp calls to perform
a couple of actions simultaniously while allowing the user to have
interaction with the form the whole time.

Is there a way to increase this limit? I noticed a Page property called
enable SessionState. If I were to set that to ReadOnly for the page causing
the extra long asyncronous request, would that free up the session to be
requested more than once?

 

[Jeff Dillon]

Oh, I see. Well, what if you put the different xmlhttp sources in different
applications on the server? I know, probably a bit of a hack, but at least
they would process their own sessions

Jeff

 

[Patrice]

What I don't undestand is that if the user just reads the page and the
request is going on in the background you shouldn't hit any server or client
side limitation.

Could it be that the long running call is called multiple times ?
What if you try a bare bone page that just sends a quick asynchronous
request. Does it shows the same problem ?

What is the exact scenario ? I assume that opening another IE session was
just for testing but that the user just display the page and doesn't
navigate while the long running request runs ?

 

[Guest]

I have simplified my process down and I believe that the long request is just
that, a long request that gets run once.

The problem is that I call one asynchronous method to download a voice file
from the database. If the file is big enough, this can take a couple of
minutes. While this file is streaming down to the client, the user is still
allowed to click buttons on the form. These button actions usually result in
some kind of server request, whether calling another xmlhttp function or
calling showModelessDialog to bring up a child form. The user is able to
click the buttons while the voice file is still streaming, but absolutly
nothing happens until the download is complete. As soon as the download
finishes, all of the other requests are processed. I would like for the user
to be able to actively interact with the form and not have to wait until the
download is finished to perform any other action.

If the voice file being downloaded is small, we never even notice, because
it downloads so quickly, but the larger the voice file, the longer the user
has to wait before he can do anything.

 

[Guest]

I tried moving the slow process to a different virtual directory on the
server, and it worked. While it was processing, I was able to make server
requests instantly against my main site. I guess I will do what I have to to
get this working, but is there another solution out there?

 

[Guest]

I got it. When I changed the EnableSessionState property of the page being
called asynchronously to ReadOnly it works. Subsequent requests are not
being blocked anymore.

 

[Juan T. Llibre]

Great tip, Harry!

Tucked away for future reference!

 

[Jeff Dillon]

Exactly. Nice work

Jeff

Great tip, Harry!

Tucked away for future reference!

 

[digitalpacman]

I am having the same issue

I have the same problem in ASP.

I think it is an IIS problem and EnableSessionState=ReadOnly for ASP.NET unsets whatever needs to be set to lock session state.

Any ideas? IIS meta base or registry settings?