7
votes

Our website uses our own custom-built session state management separate from ASP.NET Session State. But because a handful of special pages use SQL Server Reporting Services, we also need to enable ASP.NET Session State. Since we are in a load-balanced environment, we enabled the ASP.NET State Server (aspnet_state.exe or "Out-of-process Mode") on a separate backend machine.

Today I noticed that when we temporarily brought down the machine running the State Service in our Dev environment, the Dev website stopped working ("Unable to make the session state request to the session state server.") This despite having EnableSessionState="False" on the page being loaded.

Why would ASP.NET need to connect to the State Service when serving a request for a page that does not use Session State? This seems to happen even if the page does not use a Master Page, Base Page, or any User Controls. I searched through all our code-behind to ensure that we never programmatically re-enable Session State or attempt to access it.

--- EDIT AFTER MORE TROUBLESHOOTING ---

As suggested by a user below, I tried creating a web site from scratch to retest this without any complications from httpHandlers, httpModules, or other custom logic.

  1. I used Visual Studio 2008 to create a new "ASP.NET Web Site" using VB.NET.
  2. I ran the site through VS, allowing it to enable debug mode and generate a standard web.config file.
  3. I added <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" /> under the <system.web> element and started my local ASP.NET State Service".
  4. I changed the Default.aspx page's EnableSessionState to False and reloaded the page = OK.
  5. I stopped the ASP.NET State Service and reloaded the page = "Unable to make the session state request to the session state server."

At this point I was puzzled because other users claimed that they had tried something similar and did not experience the same issue. So I wondered if it had anything to do with using VB.NET (silly though that sounds.) More people use C# for ASP.NET, so I redid my test above with a C# web site, and lo and behold, no exception when accessing the page! I only got an exception if I set EnableSessionState to True and actually accessed the Session collection in code.

This proves that VB.NET sites in ASP.NET behave slightly differently in that they access session state on each page, even if the page does not need to. Unfortunately this doesn't answer my original question: Why?

I am going to cross-post this to the official ASP.NET forums and see if any gurus there can shed some light.

4
Are you using SQL Server for sesssion state, by any chance?James Johnson
No, we are using the ASP.NET State Server (aspnet_state.exe) running on a separate server. But EnableSessionState is set to False on all but a handful of pages. The question is, why does ASP.NET need to access the state server when serving pages that do not use Session State? This would seem to be a performance liability for no reason.Jordan Rieger
Did you ever come to any resolution on this?patmortech
@patmortech No, it's not really something that hurt us in Production once we knew we had to keep the ASP.NET State Service running at all times. Eventually we stopped using the state service because we realized we could change our web farm's load balancer setting from None to Affinity, meaning that clients would always talk to the same server within a session, so normal ASP.Net In-Proc session state was faster and simpler.Jordan Rieger

4 Answers

2
votes

Look for any HttpHandlers or HttpModules in your web application. It's entirely possible that these are requiring session state even though your pages are not.

1
votes

You are missing something. Because in ASP.NET Web Forms default page handler ( Page class ) doesn't implement "IRequiresSessionState" interface by default. I've tried your case with bulk ASP.NET website:

  1. Session was enabled in web.config (StateServer mode), whilst page's EnableSessionState was disabled - requests to default.aspx were processed successfully with StateServer being shut down.
  2. After enabling page's EnableSessionState - it began throwing exceptions like yours.

you can repeat same experiment easily.

0
votes

Sorry this may seem obvious but have you checked Global.asax?

0
votes

Every page request hits the underlying session provider to mark the store the session accessed time so that the session will not be cleaned up by accident. The previous state is true irrespective of the value of EnableSessionState and irrespective of Session State mode (InProc, StateServer,....).