locked
Request lockup after PostMapRequestHandler and before AcquireRequestState RRS feed

  • Question

  • User-879924683 posted

    All, 

    I am attempting to test and eventually deploy a web application on IIS7.0 Windows 2008 Server.  This web application is fairly rich and consists of several frames that often fire ASP.NET requests to the server from multiple frames simultaneously.  This application has been in production on IIS 6.0 for several years (just wanted to point out that this isn't new stuff).  Anyway, I am seeing frequent lockups of the simultaneous requests.  I have attempted several techniques to get further information about the lockups.

    FREB - The requests that lockup never complete and don't seem to ever produce a report.  Is there a way to flush FREB information about currently executing requests?

    ETW - I don't seem to be able to produce ETW output on IIS7.0 for both ASP.NET Events and IIS: WWW Server.  I can get one or the other, but not both interleaved.  Without seeing the IIS:WWW Server along side the ASP.NET Events, I can't seem to figure out where in the ASP.NET Events the locked up requests are.  I have turned all ASP.NET Event tracing on and am not sure I am getting enough detail within the pipeline to show me more than I already know.  Is there a way to get more ASP.NET pipeline diagnostics on IIS7.0 using ETW then level 5 and 0xffffffff features mask?

    Catching ASP.NET pipeline events in the debugger - This techique did allow me to narrow the problem down to after PostMapRequestHandler and before AcquireRequestState. 

    I seem to see the same problems using either the Classic or Integrated ASP.NET pipeline.

     Anyone else seeing this problem? 

    Thanks
    Steve

    Monday, December 17, 2007 12:27 PM

Answers

  • User229670690 posted

    Hi Steve,

    There is an issue I’m aware of in the Longhorn betas (any build with a System.Web.dll file version less than 2.0.50727.1431).  If you’re hitting this, you can work around it by setting a DWORD named SessionStateLockedItemPollInterval to 500 at HKLM\Software\Microsoft\ASP.NET (be sure to restart IIS after setting the registry key). 

    The Windows 2008 RC1 and later releases will not have this problem.

    Thanks,
    Thomas

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, December 17, 2007 10:58 PM

All replies

  • User229670690 posted

    Hi Steve,

    There is an issue I’m aware of in the Longhorn betas (any build with a System.Web.dll file version less than 2.0.50727.1431).  If you’re hitting this, you can work around it by setting a DWORD named SessionStateLockedItemPollInterval to 500 at HKLM\Software\Microsoft\ASP.NET (be sure to restart IIS after setting the registry key). 

    The Windows 2008 RC1 and later releases will not have this problem.

    Thanks,
    Thomas

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Monday, December 17, 2007 10:58 PM
  • User-879924683 posted

    Thomas,

     You are the man!!  I have Windows 2008 RC0.  It has version 2.0.50727.1416 of System.Web.dll.  The registry key you suggested fixes the problem.

    Thanks
    Steve

    Tuesday, December 18, 2007 3:18 PM
  • User-879924683 posted

    Thomas,

     Unfortunately, Windows 2008 RC1 seems to cause another problem I was seeing on Vista that they fixed in Vista SP1.  The problem is related to RDS not working.  The request gets sent to the server, is handled by the IIS extension for MSADC.  Unfortunately, the response is not created and sent back correctly.  Are you aware of any details related to this issue?

    Thanks,
    Steve

    Thursday, January 3, 2008 3:42 PM
  • User229670690 posted

    Hi Steve,

    I see your post at http://forums.iis.net/p/1147199/1861341.aspx#1861341, which seems to be the same question under a more appropriate title.  Unfortunately, I don't know anything about this.  I did however notice that you only posted a good FREB trace.  Could you add a bad FREB trace to the post at http://forums.iis.net/p/1147199/1861341.aspx#1861341?  Perhaps that will help shed some light on the issue.

    Thanks,
    Thomas

    Thursday, January 3, 2008 5:18 PM
  • User-879924683 posted

    Thomas,

    The bad freb request was already there, but somehow got inserted into a hidden div.  I removed the hidden div and it shows up now. 

    Thanks for responding!
    Steve

    Thursday, January 3, 2008 7:12 PM
  • User650601929 posted

    Hi, I am having the same issue! I posted my question here:

    http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.dotnet.framework.aspnet&mid=256b60aa-1aa7-453f-bef8-75c57928bed5 

    What is so weird is that initially it will work, but after I exercise some functionality in my website, it reverts back to non-concurrency. I have tried the registry key to no avail. I have confirmed through logging in an IHttpModule that it is stuck exactly between these two events.

    Any other ideas? Can someone describe this undocumented registry key and what is the problem exactly in the framework?
    Also, I have tried both InProc and SQLServer session stores.

     
    Hope someone can help, it is quite crippling to have a non-concurrent web servers..

    Thanks!

    Kevin

     

    Wednesday, January 9, 2008 8:56 PM
  • User650601929 posted

    Wow, so it turns out that this is by design:

    http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.dotnet.framework.aspnet&mid=7f56033f-caac-47c2-bd9c-95512aa14b47 

    I'm not sure what the registry key does.
     

    Wednesday, January 9, 2008 9:30 PM
  • User229670690 posted

    You normally won't have multiple requests sharing the same session ID, unless perhaps you're using HTML Frames.

    If you do have multiple requests attempting to access session state for the same session ID, some of them are going to be blocked.  Since the store can be out-of-process, the blocked callers poll the store while attempting to obtain session state.  The SessionStateLockedItemPollInterval registry key controls the poll interval.

    Finally, someone introduced a bug in the Beta and RC builds of Longhorn Sever that set the default poll interval to infinity (it was supposed to be 500 milliseconds).  So for these few builds, you have to set the registry key as a work around.

    Wednesday, January 9, 2008 10:01 PM