IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS

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.

RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS

I have upgraded to .NET SP1 and it is the same problem. It works at first,
but then it degrades back into the unworking state. I have removed the
registry key. Any ideas? How do i report a bug to MS?

RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

I also changed to SQLServer state provider and has the same behavior.

"Kevin" wrote:

> I have upgraded to .NET SP1 and it is the same problem. It works at first,
> but then it degrades back into the unworking state. I have removed the
> registry key. Any ideas? How do i report a bug to MS?

RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS

this is by design.

the lock is on session state. only one request (to the same session) is
allowed at the same time. you should not see this if session is turned off
for the page, or the requests come from two different users (sessions
actually).

the reason for this is because there is no locking code for accessing an
object in session.

you can get around this by writing your own session manager, and not
honoring the lock requests. then change all code that references a session
object to be thread safe. for out of proc session manager you will need to
maintain a current use count.

-- bruce (sqlwork.com)


"Kevin" wrote:

> 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.

RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

Wow, that's a bit surprising, although it makes some sense. I would have
thought there would at least be an option to make the default provider
"optimistic," and then require all session state modification to have a lock
around it. It seems a little bit overkill to lock the session for an entire
request?

Are there any known problems with a customer session manager? And by session
manager, do you mean a custom SessionStateStoreProviderBase? Do you know of
any existing implementations? All I'm really holding in the session is an ID
of the user, so it's not something I want to stop user-concurrent requests
for.

Thanks for your help!
Kevin

"bruce barker" wrote:

> this is by design.
>
> the lock is on session state. only one request (to the same session) is
> allowed at the same time. you should not see this if session is turned off
> for the page, or the requests come from two different users (sessions
> actually).
>
> the reason for this is because there is no locking code for accessing an
> object in session.
>
> you can get around this by writing your own session manager, and not
> honoring the lock requests. then change all code that references a session
> object to be thread safe. for out of proc session manager you will need to
> maintain a current use count.
>
> -- bruce (sqlwork.com)
>
>
> "Kevin" wrote:
>
> > 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.

RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

It seems like one option would be just to set EnableSessionState to ReadOnly
in the @Page directive:

http://msdn2.microsoft.com/en-us/library/ms178581.aspx

I think this would work for me, unless I have a WebFarm, a SQLServer Session
State provider, and the requests hit two different servers without session
afinity in the load balancer. Any other potential issues?

Kevin

"Kevin" wrote:

> Wow, that's a bit surprising, although it makes some sense. I would have
> thought there would at least be an option to make the default provider
> "optimistic," and then require all session state modification to have a lock
> around it. It seems a little bit overkill to lock the session for an entire
> request?
>
> Are there any known problems with a customer session manager? And by session
> manager, do you mean a custom SessionStateStoreProviderBase? Do you know of
> any existing implementations? All I'm really holding in the session is an ID
> of the user, so it's not something I want to stop user-concurrent requests
> for.
>
> Thanks for your help!
> Kevin
>
> "bruce barker" wrote:
>
> > this is by design.
> >
> > the lock is on session state. only one request (to the same session) is
> > allowed at the same time. you should not see this if session is turned off
> > for the page, or the requests come from two different users (sessions
> > actually).
> >
> > the reason for this is because there is no locking code for accessing an
> > object in session.
> >
> > you can get around this by writing your own session manager, and not
> > honoring the lock requests. then change all code that references a session
> > object to be thread safe. for out of proc session manager you will need to
> > maintain a current use count.
> >
> > -- bruce (sqlwork.com)
> >
> >
> > "Kevin" wrote:
> >
> > > 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.

RE: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

On further inspection, EnableSessionState="ReadOnly," truly is readonly (the
documentation hinted that you could still run into reader/writer conflicts,
so I was hoping the semantics of ReadOnly was just that it didn't lock the
session during the request and required you to put locks around session
reads/writes).

So, I am back to my original questions about how to implement the workaround
that you suggested...

Thanks!

"Kevin" wrote:

> It seems like one option would be just to set EnableSessionState to ReadOnly
> in the @Page directive:
>
> http://msdn2.microsoft.com/en-us/library/ms178581.aspx
>
> I think this would work for me, unless I have a WebFarm, a SQLServer Session
> State provider, and the requests hit two different servers without session
> afinity in the load balancer. Any other potential issues?
>
> Kevin
>
> "Kevin" wrote:
>
> > Wow, that's a bit surprising, although it makes some sense. I would have
> > thought there would at least be an option to make the default provider
> > "optimistic," and then require all session state modification to have a lock
> > around it. It seems a little bit overkill to lock the session for an entire
> > request?
> >
> > Are there any known problems with a customer session manager? And by session
> > manager, do you mean a custom SessionStateStoreProviderBase? Do you know of
> > any existing implementations? All I'm really holding in the session is an ID
> > of the user, so it's not something I want to stop user-concurrent requests
> > for.
> >
> > Thanks for your help!
> > Kevin
> >
> > "bruce barker" wrote:
> >
> > > this is by design.
> > >
> > > the lock is on session state. only one request (to the same session) is
> > > allowed at the same time. you should not see this if session is turned off
> > > for the page, or the requests come from two different users (sessions
> > > actually).
> > >
> > > the reason for this is because there is no locking code for accessing an
> > > object in session.
> > >
> > > you can get around this by writing your own session manager, and not
> > > honoring the lock requests. then change all code that references a session
> > > object to be thread safe. for out of proc session manager you will need to
> > > maintain a current use count.
> > >
> > > -- bruce (sqlwork.com)
> > >
> > >
> > > "Kevin" wrote:
> > >
> > > > 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.

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS

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" wrote in message
news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
> 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.

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

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" wrote in message
> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
> > 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.
>
>
>

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

I guess you could use EnableSessionState="ReadOnly". You should be able to
avoid locking.

It's not always about "thread" safety.
Just imagine a scenario when customer clicks "Confirm order" button. And
"double clicks" it.

Correctly written program would submit the order and then clear out shopping
cart. So when second click (it was waiting for first one to be processed)
comes in, shopping cart is empty and person is not charge twice and order
not submitted twice

With concurrent approach those double clicks will be processed
simultaneously and order will be submitted twice.
So although every single operation (updating DB, charging CC... ) is thread
safe, the whole process is not.

George.




"Kevin" wrote in message
news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
> 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" wrote in message
>> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
>> > 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.
>>
>>
>>

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

Thanks George, I understand the concern, but I can safely have concurrent
same-user requests in my application. I need to have this functionality
because I have many very independent and small AJAX requests executing, and I
will deal in code with concurrency.

I have tried EnableSessionState="ReadOnly," but then I am not able to write
into the session object. I will do *potentially* do read and write into the
session from all of my pages, so I cannot just have one login page with
EnableSessionState=true and the rest with ReadOnly.

Do I have to create some kind of custom session state provider which doesn't
have locking? If so, how do I do this?

Thanks!
Kevin

"George Ter-Saakov" wrote:

> I guess you could use EnableSessionState="ReadOnly". You should be able to
> avoid locking.
>
> It's not always about "thread" safety.
> Just imagine a scenario when customer clicks "Confirm order" button. And
> "double clicks" it.
>
> Correctly written program would submit the order and then clear out shopping
> cart. So when second click (it was waiting for first one to be processed)
> comes in, shopping cart is empty and person is not charge twice and order
> not submitted twice
>
> With concurrent approach those double clicks will be processed
> simultaneously and order will be submitted twice.
> So although every single operation (updating DB, charging CC... ) is thread
> safe, the whole process is not.
>
> George.
>
>
>
>
> "Kevin" wrote in message
> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
> > 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" wrote in message
> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
> >> > 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.
> >>
> >>
> >>
>
>
>

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

I guess, if you really know what you doing, you can write your own "Session"
Look at this article
http://msdn2.microsoft.com/en-us/library/system.web.sessions tate.sessionstateutility.aspx

Here is excerpt from this article
"The following code example shows a custom session-state module
implementation .......
This application does not prevent simultaneous Web requests from using the
same session identifier."

Seems to me exactly what you want.


George.

"Kevin" wrote in message
news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@microsoft.com...
> Thanks George, I understand the concern, but I can safely have concurrent
> same-user requests in my application. I need to have this functionality
> because I have many very independent and small AJAX requests executing,
> and I
> will deal in code with concurrency.
>
> I have tried EnableSessionState="ReadOnly," but then I am not able to
> write
> into the session object. I will do *potentially* do read and write into
> the
> session from all of my pages, so I cannot just have one login page with
> EnableSessionState=true and the rest with ReadOnly.
>
> Do I have to create some kind of custom session state provider which
> doesn't
> have locking? If so, how do I do this?
>
> Thanks!
> Kevin
>
> "George Ter-Saakov" wrote:
>
>> I guess you could use EnableSessionState="ReadOnly". You should be able
>> to
>> avoid locking.
>>
>> It's not always about "thread" safety.
>> Just imagine a scenario when customer clicks "Confirm order" button. And
>> "double clicks" it.
>>
>> Correctly written program would submit the order and then clear out
>> shopping
>> cart. So when second click (it was waiting for first one to be processed)
>> comes in, shopping cart is empty and person is not charge twice and order
>> not submitted twice
>>
>> With concurrent approach those double clicks will be processed
>> simultaneously and order will be submitted twice.
>> So although every single operation (updating DB, charging CC... ) is
>> thread
>> safe, the whole process is not.
>>
>> George.
>>
>>
>>
>>
>> "Kevin" wrote in message
>> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
>> > 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" wrote in message
>> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
>> >> > 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.
>> >>
>> >>
>> >>
>>
>>
>>

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

Thanks! That is exactly what I was looking for. I will be careful... :-)

Thanks again

"George Ter-Saakov" wrote:

> I guess, if you really know what you doing, you can write your own "Session"
> Look at this article
> http://msdn2.microsoft.com/en-us/library/system.web.sessions tate.sessionstateutility.aspx
>
> Here is excerpt from this article
> "The following code example shows a custom session-state module
> implementation .......
> This application does not prevent simultaneous Web requests from using the
> same session identifier."
>
> Seems to me exactly what you want.
>
>
> George.
>
> "Kevin" wrote in message
> news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@microsoft.com...
> > Thanks George, I understand the concern, but I can safely have concurrent
> > same-user requests in my application. I need to have this functionality
> > because I have many very independent and small AJAX requests executing,
> > and I
> > will deal in code with concurrency.
> >
> > I have tried EnableSessionState="ReadOnly," but then I am not able to
> > write
> > into the session object. I will do *potentially* do read and write into
> > the
> > session from all of my pages, so I cannot just have one login page with
> > EnableSessionState=true and the rest with ReadOnly.
> >
> > Do I have to create some kind of custom session state provider which
> > doesn't
> > have locking? If so, how do I do this?
> >
> > Thanks!
> > Kevin
> >
> > "George Ter-Saakov" wrote:
> >
> >> I guess you could use EnableSessionState="ReadOnly". You should be able
> >> to
> >> avoid locking.
> >>
> >> It's not always about "thread" safety.
> >> Just imagine a scenario when customer clicks "Confirm order" button. And
> >> "double clicks" it.
> >>
> >> Correctly written program would submit the order and then clear out
> >> shopping
> >> cart. So when second click (it was waiting for first one to be processed)
> >> comes in, shopping cart is empty and person is not charge twice and order
> >> not submitted twice
> >>
> >> With concurrent approach those double clicks will be processed
> >> simultaneously and order will be submitted twice.
> >> So although every single operation (updating DB, charging CC... ) is
> >> thread
> >> safe, the whole process is not.
> >>
> >> George.
> >>
> >>
> >>
> >>
> >> "Kevin" wrote in message
> >> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
> >> > 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" wrote in message
> >> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
> >> >> > 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.
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

just remeber you will need a lock everytime you access (read or write) an
object or its properties stored in session.


-- bruce (sqlwork.com)


"Kevin" wrote:

> Thanks! That is exactly what I was looking for. I will be careful... :-)
>
> Thanks again
>
> "George Ter-Saakov" wrote:
>
> > I guess, if you really know what you doing, you can write your own "Session"
> > Look at this article
> > http://msdn2.microsoft.com/en-us/library/system.web.sessions tate.sessionstateutility.aspx
> >
> > Here is excerpt from this article
> > "The following code example shows a custom session-state module
> > implementation .......
> > This application does not prevent simultaneous Web requests from using the
> > same session identifier."
> >
> > Seems to me exactly what you want.
> >
> >
> > George.
> >
> > "Kevin" wrote in message
> > news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@microsoft.com...
> > > Thanks George, I understand the concern, but I can safely have concurrent
> > > same-user requests in my application. I need to have this functionality
> > > because I have many very independent and small AJAX requests executing,
> > > and I
> > > will deal in code with concurrency.
> > >
> > > I have tried EnableSessionState="ReadOnly," but then I am not able to
> > > write
> > > into the session object. I will do *potentially* do read and write into
> > > the
> > > session from all of my pages, so I cannot just have one login page with
> > > EnableSessionState=true and the rest with ReadOnly.
> > >
> > > Do I have to create some kind of custom session state provider which
> > > doesn't
> > > have locking? If so, how do I do this?
> > >
> > > Thanks!
> > > Kevin
> > >
> > > "George Ter-Saakov" wrote:
> > >
> > >> I guess you could use EnableSessionState="ReadOnly". You should be able
> > >> to
> > >> avoid locking.
> > >>
> > >> It's not always about "thread" safety.
> > >> Just imagine a scenario when customer clicks "Confirm order" button. And
> > >> "double clicks" it.
> > >>
> > >> Correctly written program would submit the order and then clear out
> > >> shopping
> > >> cart. So when second click (it was waiting for first one to be processed)
> > >> comes in, shopping cart is empty and person is not charge twice and order
> > >> not submitted twice
> > >>
> > >> With concurrent approach those double clicks will be processed
> > >> simultaneously and order will be submitted twice.
> > >> So although every single operation (updating DB, charging CC... ) is
> > >> thread
> > >> safe, the whole process is not.
> > >>
> > >> George.
> > >>
> > >>
> > >>
> > >>
> > >> "Kevin" wrote in message
> > >> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
> > >> > 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" wrote in message
> > >> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
> > >> >> > 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.
> > >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> > >>
> >
> >
> >

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

One thing I don't understand is that the MSDN MySessionStateModule
IHttpModule stores the Hashtable of session objects in a private member
variable and not a static member variable -- I thought ASP.NET created a new
instance of an IHttpModule on every request. The reason I think this is that
I was having issues implementing this where every a few requests, the session
would be gone. When I changed the variables to static, things seem to work
properly.

Any thoughts?
Thanks!

"bruce barker" wrote:

> just remeber you will need a lock everytime you access (read or write) an
> object or its properties stored in session.
>
>
> -- bruce (sqlwork.com)
>
>
> "Kevin" wrote:
>
> > Thanks! That is exactly what I was looking for. I will be careful... :-)
> >
> > Thanks again
> >
> > "George Ter-Saakov" wrote:
> >
> > > I guess, if you really know what you doing, you can write your own "Session"
> > > Look at this article
> > > http://msdn2.microsoft.com/en-us/library/system.web.sessions tate.sessionstateutility.aspx
> > >
> > > Here is excerpt from this article
> > > "The following code example shows a custom session-state module
> > > implementation .......
> > > This application does not prevent simultaneous Web requests from using the
> > > same session identifier."
> > >
> > > Seems to me exactly what you want.
> > >
> > >
> > > George.
> > >
> > > "Kevin" wrote in message
> > > news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@microsoft.com...
> > > > Thanks George, I understand the concern, but I can safely have concurrent
> > > > same-user requests in my application. I need to have this functionality
> > > > because I have many very independent and small AJAX requests executing,
> > > > and I
> > > > will deal in code with concurrency.
> > > >
> > > > I have tried EnableSessionState="ReadOnly," but then I am not able to
> > > > write
> > > > into the session object. I will do *potentially* do read and write into
> > > > the
> > > > session from all of my pages, so I cannot just have one login page with
> > > > EnableSessionState=true and the rest with ReadOnly.
> > > >
> > > > Do I have to create some kind of custom session state provider which
> > > > doesn't
> > > > have locking? If so, how do I do this?
> > > >
> > > > Thanks!
> > > > Kevin
> > > >
> > > > "George Ter-Saakov" wrote:
> > > >
> > > >> I guess you could use EnableSessionState="ReadOnly". You should be able
> > > >> to
> > > >> avoid locking.
> > > >>
> > > >> It's not always about "thread" safety.
> > > >> Just imagine a scenario when customer clicks "Confirm order" button. And
> > > >> "double clicks" it.
> > > >>
> > > >> Correctly written program would submit the order and then clear out
> > > >> shopping
> > > >> cart. So when second click (it was waiting for first one to be processed)
> > > >> comes in, shopping cart is empty and person is not charge twice and order
> > > >> not submitted twice
> > > >>
> > > >> With concurrent approach those double clicks will be processed
> > > >> simultaneously and order will be submitted twice.
> > > >> So although every single operation (updating DB, charging CC... ) is
> > > >> thread
> > > >> safe, the whole process is not.
> > > >>
> > > >> George.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> "Kevin" wrote in message
> > > >> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
> > > >> > 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" wrote in message
> > > >> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
> > > >> >> > 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.
> > > >> >>
> > > >> >>
> > > >> >>
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

Looks like you were wrong.
Only one instance of IHttpModule is created per application.

George

"Kevin" wrote in message
news:E0037365-73A6-414C-8CF5-9683EF3AEC5F@microsoft.com...
> One thing I don't understand is that the MSDN MySessionStateModule
> IHttpModule stores the Hashtable of session objects in a private member
> variable and not a static member variable -- I thought ASP.NET created a
> new
> instance of an IHttpModule on every request. The reason I think this is
> that
> I was having issues implementing this where every a few requests, the
> session
> would be gone. When I changed the variables to static, things seem to work
> properly.
>
> Any thoughts?
> Thanks!
>
> "bruce barker" wrote:
>
>> just remeber you will need a lock everytime you access (read or write) an
>> object or its properties stored in session.
>>
>>
>> -- bruce (sqlwork.com)
>>
>>
>> "Kevin" wrote:
>>
>> > Thanks! That is exactly what I was looking for. I will be careful...
>> > :-)
>> >
>> > Thanks again
>> >
>> > "George Ter-Saakov" wrote:
>> >
>> > > I guess, if you really know what you doing, you can write your own
>> > > "Session"
>> > > Look at this article
>> > > http://msdn2.microsoft.com/en-us/library/system.web.sessions tate.sessionstateutility.aspx
>> > >
>> > > Here is excerpt from this article
>> > > "The following code example shows a custom session-state module
>> > > implementation .......
>> > > This application does not prevent simultaneous Web requests from
>> > > using the
>> > > same session identifier."
>> > >
>> > > Seems to me exactly what you want.
>> > >
>> > >
>> > > George.
>> > >
>> > > "Kevin" wrote in message
>> > > news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@microsoft.com...
>> > > > Thanks George, I understand the concern, but I can safely have
>> > > > concurrent
>> > > > same-user requests in my application. I need to have this
>> > > > functionality
>> > > > because I have many very independent and small AJAX requests
>> > > > executing,
>> > > > and I
>> > > > will deal in code with concurrency.
>> > > >
>> > > > I have tried EnableSessionState="ReadOnly," but then I am not able
>> > > > to
>> > > > write
>> > > > into the session object. I will do *potentially* do read and write
>> > > > into
>> > > > the
>> > > > session from all of my pages, so I cannot just have one login page
>> > > > with
>> > > > EnableSessionState=true and the rest with ReadOnly.
>> > > >
>> > > > Do I have to create some kind of custom session state provider
>> > > > which
>> > > > doesn't
>> > > > have locking? If so, how do I do this?
>> > > >
>> > > > Thanks!
>> > > > Kevin
>> > > >
>> > > > "George Ter-Saakov" wrote:
>> > > >
>> > > >> I guess you could use EnableSessionState="ReadOnly". You should be
>> > > >> able
>> > > >> to
>> > > >> avoid locking.
>> > > >>
>> > > >> It's not always about "thread" safety.
>> > > >> Just imagine a scenario when customer clicks "Confirm order"
>> > > >> button. And
>> > > >> "double clicks" it.
>> > > >>
>> > > >> Correctly written program would submit the order and then clear
>> > > >> out
>> > > >> shopping
>> > > >> cart. So when second click (it was waiting for first one to be
>> > > >> processed)
>> > > >> comes in, shopping cart is empty and person is not charge twice
>> > > >> and order
>> > > >> not submitted twice
>> > > >>
>> > > >> With concurrent approach those double clicks will be processed
>> > > >> simultaneously and order will be submitted twice.
>> > > >> So although every single operation (updating DB, charging CC... )
>> > > >> is
>> > > >> thread
>> > > >> safe, the whole process is not.
>> > > >>
>> > > >> George.
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> "Kevin" wrote in message
>> > > >> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
>> > > >> > 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" wrote in message
>> > > >> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
>> > > >> >> > 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.
>> > > >> >>
>> > > >> >>
>> > > >> >>
>> > > >>
>> > > >>
>> > > >>
>> > >
>> > >
>> > >

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

Yes, I'm sorry, you're right, only one instance, but I see that the Init
method gets called multiple times, sporadically, and sometimes pInitialized
is false again, so I don't think the example is working as expected, or my
configuration is incorrect. Any ideas?

Thanks,
Kevin

"George Ter-Saakov" wrote:

> Looks like you were wrong.
> Only one instance of IHttpModule is created per application.
>
> George
>
> "Kevin" wrote in message
> news:E0037365-73A6-414C-8CF5-9683EF3AEC5F@microsoft.com...
> > One thing I don't understand is that the MSDN MySessionStateModule
> > IHttpModule stores the Hashtable of session objects in a private member
> > variable and not a static member variable -- I thought ASP.NET created a
> > new
> > instance of an IHttpModule on every request. The reason I think this is
> > that
> > I was having issues implementing this where every a few requests, the
> > session
> > would be gone. When I changed the variables to static, things seem to work
> > properly.
> >
> > Any thoughts?
> > Thanks!
> >
> > "bruce barker" wrote:
> >
> >> just remeber you will need a lock everytime you access (read or write) an
> >> object or its properties stored in session.
> >>
> >>
> >> -- bruce (sqlwork.com)
> >>
> >>
> >> "Kevin" wrote:
> >>
> >> > Thanks! That is exactly what I was looking for. I will be careful...
> >> > :-)
> >> >
> >> > Thanks again
> >> >
> >> > "George Ter-Saakov" wrote:
> >> >
> >> > > I guess, if you really know what you doing, you can write your own
> >> > > "Session"
> >> > > Look at this article
> >> > > http://msdn2.microsoft.com/en-us/library/system.web.sessions tate.sessionstateutility.aspx
> >> > >
> >> > > Here is excerpt from this article
> >> > > "The following code example shows a custom session-state module
> >> > > implementation .......
> >> > > This application does not prevent simultaneous Web requests from
> >> > > using the
> >> > > same session identifier."
> >> > >
> >> > > Seems to me exactly what you want.
> >> > >
> >> > >
> >> > > George.
> >> > >
> >> > > "Kevin" wrote in message
> >> > > news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@microsoft.com...
> >> > > > Thanks George, I understand the concern, but I can safely have
> >> > > > concurrent
> >> > > > same-user requests in my application. I need to have this
> >> > > > functionality
> >> > > > because I have many very independent and small AJAX requests
> >> > > > executing,
> >> > > > and I
> >> > > > will deal in code with concurrency.
> >> > > >
> >> > > > I have tried EnableSessionState="ReadOnly," but then I am not able
> >> > > > to
> >> > > > write
> >> > > > into the session object. I will do *potentially* do read and write
> >> > > > into
> >> > > > the
> >> > > > session from all of my pages, so I cannot just have one login page
> >> > > > with
> >> > > > EnableSessionState=true and the rest with ReadOnly.
> >> > > >
> >> > > > Do I have to create some kind of custom session state provider
> >> > > > which
> >> > > > doesn't
> >> > > > have locking? If so, how do I do this?
> >> > > >
> >> > > > Thanks!
> >> > > > Kevin
> >> > > >
> >> > > > "George Ter-Saakov" wrote:
> >> > > >
> >> > > >> I guess you could use EnableSessionState="ReadOnly". You should be
> >> > > >> able
> >> > > >> to
> >> > > >> avoid locking.
> >> > > >>
> >> > > >> It's not always about "thread" safety.
> >> > > >> Just imagine a scenario when customer clicks "Confirm order"
> >> > > >> button. And
> >> > > >> "double clicks" it.
> >> > > >>
> >> > > >> Correctly written program would submit the order and then clear
> >> > > >> out
> >> > > >> shopping
> >> > > >> cart. So when second click (it was waiting for first one to be
> >> > > >> processed)
> >> > > >> comes in, shopping cart is empty and person is not charge twice
> >> > > >> and order
> >> > > >> not submitted twice
> >> > > >>
> >> > > >> With concurrent approach those double clicks will be processed
> >> > > >> simultaneously and order will be submitted twice.
> >> > > >> So although every single operation (updating DB, charging CC... )
> >> > > >> is
> >> > > >> thread
> >> > > >> safe, the whole process is not.
> >> > > >>
> >> > > >> George.
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> "Kevin" wrote in message
> >> > > >> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
> >> > > >> > 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" wrote in message
> >> > > >> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
> >> > > >> >> > 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.
> >> > > >> >>
> >> > > >> >>
> >> > > >> >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >> > >
>
>
>

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

Is it possible that your application restarts all the time?

Have folowing code in your global.asax, you will need to create
SendEmail(msg, ssubj, to) function so every time your app restarts you will
get an email.

George.


protected void Application_End(Object sender, EventArgs e)
{
HttpRuntime runtime =
(HttpRuntime)typeof(System.Web.HttpRuntime).InvokeMember("_t heRuntime",

BindingFlags.NonPublic

| BindingFlags.Static

| BindingFlags.GetField,

null,

null,

null);
if (runtime == null)
return;
string shutDownMessage =
(string)runtime.GetType().InvokeMember("_shutDownMessage",
BindingFlags.NonPublic
|
BindingFlags.Instance
|
BindingFlags.GetField,
null,
runtime,
null);
string shutDownStack =
(string)runtime.GetType().InvokeMember("_shutDownStack",
BindingFlags.NonPublic
|
BindingFlags.Instance
|
BindingFlags.GetField,
null,
runtime,
null);

//send email to me
SendEmail(String.Format("\r\n\r\n_shutDownMessage={0}\r\n\r\ n_shutDownStack={1}",
shutDownMessage,
shutDownStack), "Application Shutdown",
"myemail@comcast.net");
}

George.

"Kevin" wrote in message
news:EC9BD1EB-9047-454C-B940-33F6A3045792@microsoft.com...
> Yes, I'm sorry, you're right, only one instance, but I see that the Init
> method gets called multiple times, sporadically, and sometimes
> pInitialized
> is false again, so I don't think the example is working as expected, or my
> configuration is incorrect. Any ideas?
>
> Thanks,
> Kevin
>
> "George Ter-Saakov" wrote:
>
>> Looks like you were wrong.
>> Only one instance of IHttpModule is created per application.
>>
>> George
>>
>> "Kevin" wrote in message
>> news:E0037365-73A6-414C-8CF5-9683EF3AEC5F@microsoft.com...
>> > One thing I don't understand is that the MSDN MySessionStateModule
>> > IHttpModule stores the Hashtable of session objects in a private member
>> > variable and not a static member variable -- I thought ASP.NET created
>> > a
>> > new
>> > instance of an IHttpModule on every request. The reason I think this is
>> > that
>> > I was having issues implementing this where every a few requests, the
>> > session
>> > would be gone. When I changed the variables to static, things seem to
>> > work
>> > properly.
>> >
>> > Any thoughts?
>> > Thanks!
>> >
>> > "bruce barker" wrote:
>> >
>> >> just remeber you will need a lock everytime you access (read or write)
>> >> an
>> >> object or its properties stored in session.
>> >>
>> >>
>> >> -- bruce (sqlwork.com)
>> >>
>> >>
>> >> "Kevin" wrote:
>> >>
>> >> > Thanks! That is exactly what I was looking for. I will be careful...
>> >> > :-)
>> >> >
>> >> > Thanks again
>> >> >
>> >> > "George Ter-Saakov" wrote:
>> >> >
>> >> > > I guess, if you really know what you doing, you can write your own
>> >> > > "Session"
>> >> > > Look at this article
>> >> > > http://msdn2.microsoft.com/en-us/library/system.web.sessions tate.sessionstateutility.aspx
>> >> > >
>> >> > > Here is excerpt from this article
>> >> > > "The following code example shows a custom session-state module
>> >> > > implementation .......
>> >> > > This application does not prevent simultaneous Web requests from
>> >> > > using the
>> >> > > same session identifier."
>> >> > >
>> >> > > Seems to me exactly what you want.
>> >> > >
>> >> > >
>> >> > > George.
>> >> > >
>> >> > > "Kevin" wrote in message
>> >> > > news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@microsoft.com...
>> >> > > > Thanks George, I understand the concern, but I can safely have
>> >> > > > concurrent
>> >> > > > same-user requests in my application. I need to have this
>> >> > > > functionality
>> >> > > > because I have many very independent and small AJAX requests
>> >> > > > executing,
>> >> > > > and I
>> >> > > > will deal in code with concurrency.
>> >> > > >
>> >> > > > I have tried EnableSessionState="ReadOnly," but then I am not
>> >> > > > able
>> >> > > > to
>> >> > > > write
>> >> > > > into the session object. I will do *potentially* do read and
>> >> > > > write
>> >> > > > into
>> >> > > > the
>> >> > > > session from all of my pages, so I cannot just have one login
>> >> > > > page
>> >> > > > with
>> >> > > > EnableSessionState=true and the rest with ReadOnly.
>> >> > > >
>> >> > > > Do I have to create some kind of custom session state provider
>> >> > > > which
>> >> > > > doesn't
>> >> > > > have locking? If so, how do I do this?
>> >> > > >
>> >> > > > Thanks!
>> >> > > > Kevin
>> >> > > >
>> >> > > > "George Ter-Saakov" wrote:
>> >> > > >
>> >> > > >> I guess you could use EnableSessionState="ReadOnly". You should
>> >> > > >> be
>> >> > > >> able
>> >> > > >> to
>> >> > > >> avoid locking.
>> >> > > >>
>> >> > > >> It's not always about "thread" safety.
>> >> > > >> Just imagine a scenario when customer clicks "Confirm order"
>> >> > > >> button. And
>> >> > > >> "double clicks" it.
>> >> > > >>
>> >> > > >> Correctly written program would submit the order and then clear
>> >> > > >> out
>> >> > > >> shopping
>> >> > > >> cart. So when second click (it was waiting for first one to be
>> >> > > >> processed)
>> >> > > >> comes in, shopping cart is empty and person is not charge twice
>> >> > > >> and order
>> >> > > >> not submitted twice
>> >> > > >>
>> >> > > >> With concurrent approach those double clicks will be processed
>> >> > > >> simultaneously and order will be submitted twice.
>> >> > > >> So although every single operation (updating DB, charging
>> >> > > >> CC... )
>> >> > > >> is
>> >> > > >> thread
>> >> > > >> safe, the whole process is not.
>> >> > > >>
>> >> > > >> George.
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >> "Kevin" wrote in message
>> >> > > >> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
>> >> > > >> > 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" wrote in message
>> >> > > >> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
>> >> > > >> >> > 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.
>> >> > > >> >>
>> >> > > >> >>
>> >> > > >> >>
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > >
>> >> > >
>> >> > >
>>
>>
>>

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

Hi George, I added debug statements to both Application_Start and
Application_End, and I only see one debug line coming out of
Application_Start, as expected. I also added some debug to the MSDN class in
the Init method, and Init gets called more than once, and sometimes
pInitialized is false (and therefore the hash table is different and my
session is not found):

public void Init(HttpApplication app)
{
....
if (!pInitialized)
{
lock (typeof(ConcurrentSessionStateModule))
{
if (!pInitialized)
{
if (Log.Enabled) Log.LogDebug10("Initializing {0}",
this.GetType().Name);

Is it correct that Init is getting called more than once even though
Application_Start only gets called once?

Thanks for your help

"George Ter-Saakov" wrote:

> Is it possible that your application restarts all the time?
>
> Have folowing code in your global.asax, you will need to create
> SendEmail(msg, ssubj, to) function so every time your app restarts you will
> get an email.
>
> George.
>
>
> protected void Application_End(Object sender, EventArgs e)
> {
> HttpRuntime runtime =
> (HttpRuntime)typeof(System.Web.HttpRuntime).InvokeMember("_t heRuntime",
>
> BindingFlags.NonPublic
>
> | BindingFlags.Static
>
> | BindingFlags.GetField,
>
> null,
>
> null,
>
> null);
> if (runtime == null)
> return;
> string shutDownMessage =
> (string)runtime.GetType().InvokeMember("_shutDownMessage",
> BindingFlags.NonPublic
> |
> BindingFlags.Instance
> |
> BindingFlags.GetField,
> null,
> runtime,
> null);
> string shutDownStack =
> (string)runtime.GetType().InvokeMember("_shutDownStack",
> BindingFlags.NonPublic
> |
> BindingFlags.Instance
> |
> BindingFlags.GetField,
> null,
> runtime,
> null);
>
> //send email to me
> SendEmail(String.Format("\r\n\r\n_shutDownMessage={0}\r\n\r\ n_shutDownStack={1}",
> shutDownMessage,
> shutDownStack), "Application Shutdown",
> "myemail@comcast.net");
> }
>
> George.
>
> "Kevin" wrote in message
> news:EC9BD1EB-9047-454C-B940-33F6A3045792@microsoft.com...
> > Yes, I'm sorry, you're right, only one instance, but I see that the Init
> > method gets called multiple times, sporadically, and sometimes
> > pInitialized
> > is false again, so I don't think the example is working as expected, or my
> > configuration is incorrect. Any ideas?
> >
> > Thanks,
> > Kevin
> >
> > "George Ter-Saakov" wrote:
> >
> >> Looks like you were wrong.
> >> Only one instance of IHttpModule is created per application.
> >>
> >> George
> >>
> >> "Kevin" wrote in message
> >> news:E0037365-73A6-414C-8CF5-9683EF3AEC5F@microsoft.com...
> >> > One thing I don't understand is that the MSDN MySessionStateModule
> >> > IHttpModule stores the Hashtable of session objects in a private member
> >> > variable and not a static member variable -- I thought ASP.NET created
> >> > a
> >> > new
> >> > instance of an IHttpModule on every request. The reason I think this is
> >> > that
> >> > I was having issues implementing this where every a few requests, the
> >> > session
> >> > would be gone. When I changed the variables to static, things seem to
> >> > work
> >> > properly.
> >> >
> >> > Any thoughts?
> >> > Thanks!
> >> >
> >> > "bruce barker" wrote:
> >> >
> >> >> just remeber you will need a lock everytime you access (read or write)
> >> >> an
> >> >> object or its properties stored in session.
> >> >>
> >> >>
> >> >> -- bruce (sqlwork.com)
> >> >>
> >> >>
> >> >> "Kevin" wrote:
> >> >>
> >> >> > Thanks! That is exactly what I was looking for. I will be careful...
> >> >> > :-)
> >> >> >
> >> >> > Thanks again
> >> >> >
> >> >> > "George Ter-Saakov" wrote:
> >> >> >
> >> >> > > I guess, if you really know what you doing, you can write your own
> >> >> > > "Session"
> >> >> > > Look at this article
> >> >> > > http://msdn2.microsoft.com/en-us/library/system.web.sessions tate.sessionstateutility.aspx
> >> >> > >
> >> >> > > Here is excerpt from this article
> >> >> > > "The following code example shows a custom session-state module
> >> >> > > implementation .......
> >> >> > > This application does not prevent simultaneous Web requests from
> >> >> > > using the
> >> >> > > same session identifier."
> >> >> > >
> >> >> > > Seems to me exactly what you want.
> >> >> > >
> >> >> > >
> >> >> > > George.
> >> >> > >
> >> >> > > "Kevin" wrote in message
> >> >> > > news:DDA903F7-8D25-46E4-AA1A-52BD0005B98D@microsoft.com...
> >> >> > > > Thanks George, I understand the concern, but I can safely have
> >> >> > > > concurrent
> >> >> > > > same-user requests in my application. I need to have this
> >> >> > > > functionality
> >> >> > > > because I have many very independent and small AJAX requests
> >> >> > > > executing,
> >> >> > > > and I
> >> >> > > > will deal in code with concurrency.
> >> >> > > >
> >> >> > > > I have tried EnableSessionState="ReadOnly," but then I am not
> >> >> > > > able
> >> >> > > > to
> >> >> > > > write
> >> >> > > > into the session object. I will do *potentially* do read and
> >> >> > > > write
> >> >> > > > into
> >> >> > > > the
> >> >> > > > session from all of my pages, so I cannot just have one login
> >> >> > > > page
> >> >> > > > with
> >> >> > > > EnableSessionState=true and the rest with ReadOnly.
> >> >> > > >
> >> >> > > > Do I have to create some kind of custom session state provider
> >> >> > > > which
> >> >> > > > doesn't
> >> >> > > > have locking? If so, how do I do this?
> >> >> > > >
> >> >> > > > Thanks!
> >> >> > > > Kevin
> >> >> > > >
> >> >> > > > "George Ter-Saakov" wrote:
> >> >> > > >
> >> >> > > >> I guess you could use EnableSessionState="ReadOnly". You should
> >> >> > > >> be
> >> >> > > >> able
> >> >> > > >> to
> >> >> > > >> avoid locking.
> >> >> > > >>
> >> >> > > >> It's not always about "thread" safety.
> >> >> > > >> Just imagine a scenario when customer clicks "Confirm order"
> >> >> > > >> button. And
> >> >> > > >> "double clicks" it.
> >> >> > > >>
> >> >> > > >> Correctly written program would submit the order and then clear
> >> >> > > >> out
> >> >> > > >> shopping
> >> >> > > >> cart. So when second click (it was waiting for first one to be
> >> >> > > >> processed)
> >> >> > > >> comes in, shopping cart is empty and person is not charge twice
> >> >> > > >> and order
> >> >> > > >> not submitted twice
> >> >> > > >>
> >> >> > > >> With concurrent approach those double clicks will be processed
> >> >> > > >> simultaneously and order will be submitted twice.
> >> >> > > >> So although every single operation (updating DB, charging
> >> >> > > >> CC... )
> >> >> > > >> is
> >> >> > > >> thread
> >> >> > > >> safe, the whole process is not.
> >> >> > > >>
> >> >> > > >> George.
> >> >> > > >>
> >> >> > > >>
> >> >> > > >>
> >> >> > > >>
> >> >> > > >> "Kevin" wrote in message
> >> >> > > >> news:2E592DB0-8809-4C5F-BC36-B9AC0DECA1D0@microsoft.com...
> >> >> > > >> > 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" wrote in message
> >> >> > > >> >> news:256B60AA-1AA7-453F-BEF8-75C57928BED5@microsoft.com...
> >> >> > > >> >> > 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);
> >> >> > > >> >> > }
> >> >> > > >> >> >

Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ

What can I say.... I can not get the behavior you are getting.
My Init method is only called once..... I even plugged that Session module
from MSDN....Just make a clean one page application and try to reproduce
that behavior.


Here is couple points to look at, my guess might lead to that behavior

1. Your Init(HttpApplication app) throws an error and Module is never
initializing. Then i think .NET might repeatedly call Init method.

2. Your application is restarting all the time. If you do it in development
then everytime you recompile project it restarts application.


George.

"Kevin" wrote in message
news:A32D7B3B-0FAB-4908-A514-E980ECEE77C9@microsoft.com...
> Hi George, I added debug statements to both Application_Start and
> Application_End, and I only see one debug line coming out of
> Application_Start, as expected. I also added some debug to the MSDN class
> in
> the Init method, and Init gets called more than once, and sometimes
> pInitialized is false (and therefore the hash table is different and my
> session is not found):
>
> public void Init(HttpApplication app)
> {
> ...
> if (!pInitialized)
> {
> lock (typeof(ConcurrentSessionStateModule))
> {
> if (!pInitialized)
> {
> if (Log.Enabled) Log.LogDebug10("Initializing {0}",
> this.GetType().Name);
>
> Is it correct that Init is getting called more than once even though
> Application_Start only gets called once?
>
> Thanks for your help
>