Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
- From: Kevin <Kevin@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 10 Jan 2008 06:43:03 -0800
Thanks for the reply, I am interested in working around this design because
all I store in the session is an integer ID which I map to internal
constructs that are thread safe. How can I work around this limitation yet
still have EnableSessionState = true? Bruce mentioned a custom provider which
doesn't adhere to the lock. Are there any examples of this?
Thanks!
Kevin
"George Ter-Saakov" wrote:
Different users will not block each other. Only same user who is hitting the.
same session.
You can not have 2 simultaneous request for the same session. And it's
actually a good thing and done for your own benefits.
George
"Kevin" <Kevin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:256B60AA-1AA7-453F-BEF8-75C57928BED5@xxxxxxxxxxxxxxxx
Hi, I am running Win2K3 Server Enterprise Edition SP2, and I have logged
that
requests are not running concurrently. I created an IHttpModule and
printed
debug on every event, and found that when one long running request is
processing, another request comes in and pauses between
PostMapRequestHandler
and AcquireRequestState. When the original request completes, this second
request continues.
I have found this article describing the same problem and a fix using an
undocumented registry key SessionStateLockedItemPollInterval in
HKLM\Software\Microsoft\ASP.NET:
http://forums.iis.net/t/1147300.aspx
First, I am running a current version of IIS, and Windows, so
theoretically
this should be fixed, but the weirdest thing happens. So, I put in this
registry value, and everything is fixed, until I do some action in my app
(don't understand what), and for the rest of the life of the AppDomain, it
reverts to old serialized behavior. If I restart the computer, again it
works.
My test case is simple. There is slow.aspx:
public partial class slow : System.Web.UI.Page
{
public override void ProcessRequest(HttpContext context)
{
// [LOG here]
base.ProcessRequest(context);
}
protected void Page_Load(object sender, EventArgs e)
{
// [LOG here]
Thread.Sleep(8000);
Response.Output.Write("SlowResponse, threadid={0}",
Thread.CurrentThread.ManagedThreadId);
}
}
Then there is fast.aspx:
public partial class fast : System.Web.UI.Page
{
public override void ProcessRequest(HttpContext context)
{
// [LOG here]
base.ProcessRequest(context);
}
protected void Page_Load(object sender, EventArgs e)
{
// [LOG here]
Response.Output.Write("FastResponse, threadid={0}",
Thread.CurrentThread.ManagedThreadId);
}
}
On my local IIS or VS web server, this works fine of course. I run
slow.aspx, and after a few seconds, run fast.aspx -- it should display
immediately while slow.aspx spins.
On my remote IIS, except for the "initial" instances with the registry
value, I run slow.aspx, and a few seconds later, fast.aspx, and fast.aspx
only comes back after slow.aspx finishes. And of course, looking at the
logging, I have confirmed this is not just a remote connection issue, but
I
can actually see the BeingRequest come in for fast.aspx, and it only hits
AcquireRequestState after slow.aspx hits EndRequest.
This problem is baffling, and the fact that the registry key only
sporadically works, I'm not sure what to do. I am trying to upgrade .NET
2.0
to SP1 and see if that works....
Please help! Serialized access web servers would suck! :-) [of course, I
know it is some kind of bug]
By the way, I am currently using InProc for the session store.
- Follow-Ups:
- Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
- From: George Ter-Saakov
- Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
- References:
- IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS
- From: Kevin
- Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS
- From: George Ter-Saakov
- IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS
- Prev by Date: Re: Format text in label to amount
- Next by Date: Re: C# or VB.NET?
- Previous by thread: Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS
- Next by thread: Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
- Index(es):
Relevant Pages
|
Loading