Requests hanging on Session module on IIS 7.5

问题:

From time to time, some requests on my website starts to hang on the RequestAcquireState state of the Session module. When that spiral begins all requests timeout and we need to restart the IIS on the affected server.

I investigated it a lot and the only conclusion I got is that somehow a deadlock is happening while the application tries to access user data stored in Session.

The only option I can think of to fix this issue is to either reduce or stop using Sessions in my application. This is definetely part of the plan, but it will take a while before we can complete that.

We run 6 machines with IIS 7.5, out of proc StateServer and server affinity on in our Load Balance.

Any hints on how to workaround this issue or fix it at all without having to remove Sessions entirely?

回答1:

Lock mechanism exist on both provider and session module (IIS Session Module). You can develop custom session module, but you still need provider without locking or You can develop custom provider without locking but you still need IIS session module and it is not so simple to implement at that level.

The Solution is UnlockedStateProvider [aka Unlocked]

Follow the white rabbit :P (Check the demo project, it explains everything.)

回答2:

The answer is Hotfix Rollup 2828841 for .NET Framework 4.5 , here all the explanation:

http://forums.asp.net/t/1888889.aspx/2/10?Question+regarding+a+possible+bug+within+NET+4+5

and here the download link

It works for me on IIS 7.5 Windows Server 2008 rs x64 , asp.net web forms application with lot of ajax request.

回答3:

I just found out today that if you have a long running request (or in my case, an infinite loop), then all subsequent requests will be locked, because by default ASP.NET locks on session.

So if you have users with requests in RequestAcquireState, then check if there is a request in ExecuteRequestHandler that is locking the session, and thus preventing other requests from starting.

There is a discussion here on how to prevent locking on session. (Basically, create most of your pages as Session-Read-Only, and modify session as rarely as you can.)

回答4:

Is it possible those users have another long running request and the requests you see piling up are actually secondary requests? By default, ASP.NET will lock Session until a request is complete. If a second request comes in before the first one is complete, it will have to wait. If you are using MVC, you can change this behavior by adding an attribute to your controller.

[SessionState(SessionStateBehavior.ReadOnly)]

This makes Session read-only, removing the locking behavior allowing subsequent requests to be processed.