views:

1281

answers:

5

Here is my current question:

I'm guessing that my problem (described below) is being caused by ASP.NET worker processes being recycled, per the answers below—I'm using InProc sessions storage and don't see much chance of moving away, due to the restriction for other types of storage that all session objects be serializable. However, I can't figure out what would make the worker process be recycled as often as I'm seeing it—there wasn't any changing of the files in the app directory as far as I know, and the options in IIS seem to imply that the process would only be recycled every 1,740 minutes—which is much less frequent than the actual session loss. So, my question is now, what different cases can cause an ASP.NET worker process to be recycled?

Here is my original question:

I have a difficult-to-reproduce problem that occurs in my ASP.NET web application. The application has one main .aspx page that is loaded and initializes a number of session variables. This page uses the ASP.NET Ajax Sys.Net.WebRequest class to repeatedly access another .aspx page, which uses the session variables to make database queries and update the main page (the main page is never re-requested).

Occasionally, after a period of time using the page, causing successful HTTP requests where the session created in the main page properly carries over to the subpage, one of the requests seems to cause a new ASP.NET session to be created—all the session variables are lost (causing an exception to be thrown in my code), and a new session id is reported in the dynamically requested page. That means that suddenly, the main page is disconnected from the server—as far as the server is concerned, the user is no longer logged in.

I'm nearly positive it's not a session timeout—the timeout time is set to something ridiculous, the amount of time it takes to get this to happen is variable but is never long enough to cause the session to time out, and the constant Sys.Net.WebRequests should refresh the session timer.

So, what else could be happening that would cause the HTTP requests to lose contact with the ASP.NET session? I unfortunately haven't been sniffing network traffic when this has happened to me, or I would've checked if the ASP.NET session cookie has stuck around or not.

+1  A: 

The worker process is probably cycling. http://www.lattimore.id.au/2006/06/03/iis-dropping-sessions/

Bloodhound
Actually...When a worker process recycles, the original process continues running and servicing requests for existing sessions until such time there are no remaining ASP.NET sessions. All *new* sessions are created in the new worker process. Classic ASP sessions are however lost.
Kev
From what I've read, if your ASP.NET application is using InProc session management, then it will indeed be lost if your worker process is recycled.
John Calsbeek
+3  A: 

One solution would be to use a StateServer, rather than InProc session management.

Lots of things can cause the session state to be lost:

  1. Editing Web.Config
  2. IIS resetting
  3. etc.

If the session state is important to your app then use either SQL state management, or the State Server which ships with ASP. NET.

Cheers,

RB.

RB
+1  A: 

It could be caused by an unhandled exception in a background thread. It can cause your ASP.NET worker process to terminate. A new process is started very quickly so you don't actually notice it but all your sessions are lost.

Here is an article that explains it much better than I can: ASP.NET 2.0 Unhandled Exception Issues

quote:

An unhandled exception in a running ASP.NET 2.0 application will usually terminate the W3WP.exe process, and leave you with a very cryptic EventLog entry something like this:

"EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.1830, P3 42435be1, P4 app_web_ncsnb2-n, P5 0.0.0.0, P6 440a4082, P7 5, P8 1, P9 system.nullreferenceexception, P10 NIL."

Here is a Microsoft KB article that explains the same issue: KB911816 Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0

Remko Jansen
+1  A: 

My guess would be memory consumption - but, set up IIS to log recycles and you'll know for sure.

Mark Brackett
+3  A: 

We had problems of Session when we did migrating the AnkerEx application to the new server. The new server had Microsoft Windows Server 2008 as operation system and Microsoft Internet Information Services 7. Also in the server were installed .NET Framework of versions 1.0.3705, 1.1.4322, 2.0.50727, 3.0 and 3.5. For solving of this problem i have done enabling health monitoring for application's Lifetime related events in ASP.NET 2.0. I had added to the web.config:

...
...
<system.web>
...
...
    <healthMonitoring>
      <rules>
        <add name="Application Events"
            eventName="Application Lifetime Events"
            provider="EventLogProvider"
            profile="Default"
            minInterval="00:01:00" />
      </rules>
    </healthMonitoring>
...
...

It is help to us to check the AppDomain recycles. We can see it at our Event Viewer. The link to more details is http://blogs.msdn.com/rahulso/archive/2006/04/13/575715.aspx

After I have done adding to web.config, the Event Viewer showed me that my application is restarting every time when i do click to almost any link in my application. From the article of http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx i found out that ASP.NET has the new behavior - if we will do deleting, for example a sub-directory of the application's root directory, then ASP.NET 2.0 will do the restarting AppDomain.

The problem was in that that I had in the web.config the instruction:

...
<compilation debug="true" tempDirectory="c:\AnkerEx\Temporary ASP.NET files">
...

I.e. the ASP.NET did compiling of aspx pages in folder of my application root. I think he created folders, may be and did removing some of them also. I removed tempDirectory instruction and the application began work stable.