IIS bug-Concurrent request lock before IHttpModule.AcquireRequestS

[Kevin]

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.

[Kevin]

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?

[Kevin]

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

[bruce barker]

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]

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

[Kevin]

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]

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!

[George Ter-Saakov]

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

[Kevin]

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]

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" <Ke...@discussions.microsoft.com> wrote in message

news:2E592DB0-8809-4C5F...@microsoft.com...

[Kevin]

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?

[George Ter-Saakov]

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.sessionstate.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" <Ke...@discussions.microsoft.com> wrote in message

news:DDA903F7-8D25-46E4...@microsoft.com...

[Kevin]

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

Thanks again

[bruce barker]

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]

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!

[George Ter-Saakov]

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

George

"Kevin" <Ke...@discussions.microsoft.com> wrote in message

news:E0037365-73A6-414C...@microsoft.com...

[Kevin]

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]

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("_theRuntime",

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",
"mye...@comcast.net");
}

George.

"Kevin" <Ke...@discussions.microsoft.com> wrote in message

news:EC9BD1EB-9047-454C...@microsoft.com...

[Kevin]

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]

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" <Ke...@discussions.microsoft.com> wrote in message

news:A32D7B3B-0FAB-4908...@microsoft.com...