locked
IIS 7.5 Web Garden Random Logouts RRS feed

  • Question

  • User1966400441 posted

    Note: This post doesn't quite fit any of the MSDN Forum categories or the ASP.NET Forum categories, so I apologize if it's in the wrong place.

    I have an ASP.NET web application that works great under the default 1 .NET worker process (non-web garden) configuration. However, recent massive increases in customer base have presented performance issues. We're tackling this on multiple fronts (i.e. app performance issues and load balancing). On our way to full load balancing, we are taking the interim step of enabling a web garden on the current Windows Server 2008 R2 IIS 7.5 server.

    In order to handle session from multiple, independent worker processes, I have setup a SQL state database and switched the application from InProc to SQLServer for state storage. This worked great. I can see both the application and sessions appear in the tables and the application keeps state as it should.

    Here is where the problem occurs. In a test environment, with SQL state now configured, I enabled 4 worker processes on the current, functional app pool. When this is set to anything except 1, the application becomes unstable and randomly dumps users out to the apprestart/logon page. I have checked application logs, IIS logs and the Windows event logs. There are no errors anywhere. It's as if you're using the application one minute and the next the app has either restarted or it has lost your session.

    Does anyone have any ideas as to where to look next?

    Friday, September 20, 2019 1:03 PM

All replies

  • User475983607 posted

    Set a specific machine key in the web.config.   The machine key is used to decrypt ViewState, Session, and form auth cookies. 

    It's not real clear what .NET features your application uses.  You need to be mindful of how your app manages state for example cache will exist for each worker process. 

    Friday, September 20, 2019 1:22 PM
  • User1966400441 posted

    Thank you. I didn't think in a web garden configuration (single server, multiple worker processes) required a manual machine key be set. However, I did so and tested again, but received the same results. Application works fine until you're suddenly logged out. The session ID doesn't change though.

    Friday, September 20, 2019 4:11 PM
  • User475983607 posted

    How does your security work?  How is the user login persisted?

    Friday, September 20, 2019 4:26 PM
  • User1966400441 posted

    In addition to the HttpContext.Current.User AuthorizedPrincipal, we also store various aspects of user information (e.g. user ID) in the session.

    Monday, September 23, 2019 5:00 PM
  • User475983607 posted

    In addition to the HttpContext.Current.User AuthorizedPrincipal, we also store various aspects of user information (e.g. user ID) in the session.

    Still unclear. 

    If you are using the standard .NET security APIs which stores the user token in an auth cookie then a machine key must be specified.  Otherwise, the application domains that did not create the auth cookie will not be able to decrypt the token within the cookie.  Same concept applies to ViewState.

    If you have custom security logic based on Session then I assume there is a logical bug in the custom code.  Find where the code redirects and review the logic. 

    Monday, September 23, 2019 5:53 PM
  • User1966400441 posted

    I set the machine key. However, when this occurs, I don't receive breaks on application error, application end or session end. I just came across something that might explain it though.

    I noticed in the Event Viewer > System, that WAS logged the following 2 events.

    1. A process serving application pool 'VMS' failed to respond to a ping. The process id was '18804'.
    2. A worker process with pid '18804' that serves application pool 'VMS' has been determined to be unhealthy (see previous event log message), but because a debugger is attached to it, the Windows Process Activation Service will ignore the error.

    Just before seeing those events, I also noticed that one of the 4 worker processes had a different type than the rest. Guess what... it was PID 18804.

    Processes

    These are the processes for the service account running our site.

    • PID: 18804, Title: {blank}, Type: x64
    • PID: 2552, Title: C:\Windows\System32\inetsrv\w3wp.exe, Type: Managed (v4.6, v4.5, v4.0)
    • PID: 7452, Title: C:\Windows\System32\inetsrv\w3wp.exe, Type: Managed (v4.6, v4.5, v4.0)
    • PID: 13260, Title: C:\Windows\System32\inetsrv\w3wp.exe, Type: Managed (v4.6, v4.5, v4.0)

    I'm taking a guess that PID 18804 is not running as the correct type, causing it not to service requests. This in turn causes the process not to respond to health pings, which in turn terminates the process as unhealthy, thus causing the crash.

    What do you think?

    Monday, September 23, 2019 6:40 PM