Is "InProc" suitable for production Session State?

[James Hunter Ross]

We love the ASP.NET "Session" concept and make good use of it. But, getting
close to deployment we find we lose sessions far too often, probably due to
application restarts, etc. We hope to eliminate these restarts, but we're
not sure that can be achieved. (We are exploring who/what might be touching
web.config or assemblies or other files in our application, but have found
nothing so far.)

We have some serious rewriting to do if all our session stuff is to be made
"serializable" and thus suitable for State Server or SQL Server persistence.

An even bigger rewrite issue concerns the fact that much of our "state" IS
an actual SQL Server connection with all associated temp tables and
recordsets. (We can't use ADO.NET and just call our legacy API which is
ODBC based. When the ASP.NET session goes away, we let go of the DB
connection too.)

So, is it realistic to expect to use the InProc model in a production
application? Is it just impossible to ensure reasonable periods of time
where application restarts will not occur?

Any thoughts will be very much appreciated! We're working hard to get up to
speed on session and stability aspects of deployment.

James

 

[Juan T. Llibre]

re:

So, is it realistic to expect to use the InProc model in a production application?

Short answer : no.

re:

Is it just impossible to ensure reasonable periods of time where application restarts
will not occur?

Application restarts will occur anyway, no matter the parameters.

Preserving state will only be reliable if you
use State Server or SQL Server to maintain state.

 

[Bruce Barker]

you started out with a pretty poor, non-scalable design, so now you are in
band-aid mode. i wouldn't use inproc sessions for any production app, unless
the session data can be regen'd on a recycle.

to stop recycles be sure to turn off the recycles due to inactivity. also
set the memory constraints very high, (recycles may happen if too many
sessions are created due to memory footprint). only deploy fix at off hours
(as this will cause a recycle). turn off anti-virus software scanning of
your vdirs.

-- bruce (sqlwork.com)

 

[JIMCO Software]

re:

Short answer : no.

re:

Application restarts will occur anyway, no matter the parameters.

Preserving state will only be reliable if you
use State Server or SQL Server to maintain state.

I disagree. I work with enterprise customers running huge Web sites every
day that use InProc without a problem. There are times when using
out-of-proc Session state is a good idea, but app restarts isn't one of
them. You should address that problem.

There are other drawbacks to app domain restarts. You have to start your
app back up each time this happens. That means you have to re-JIT, heaps
have to be re-grown, allocation patterns have to be re-established, etc.
It's just a bad idea to allow app domain restarts to occur regularly if you
can avoid it. In my experience, you always can.

If you give Microsoft a call, you can get an HttpModule that is designed to
track app domain restarts, when they occur, and why.

 

[Juan T. Llibre]

Regardless of your disagreement, application restarts
*will* occur, no matter which state management methods is used.

There are times when using out-of-proc Session state is a good idea, but app restarts
isn't one of them.

If your app restarts and you're using InProc state management,
you *will* lose session variables.

The *only* way to prevent that is to use
either State Server or SQL Server state management.

Sorry, Jim, you're just plain wrong on this one.

re:

It's just a bad idea to allow app domain restarts to occur regularly if you can avoid
it. In my experience, you always can.

Please outline a way to avoid Application restarts, and loss of
session variables if you're using Inproc State Management.

 

[James Hunter Ross]

Thank you gentlemen!

We've got some homework to do now. Restarts will occur, now we need to
determine how often they are likely and what we can do to minimize them. We
are not in a position to avoid InProc because of legacy backend issues. We
are guessing that maybe good old fashioned bugs in our own ASP.NET code
might be contributing to the frequency of process and application restarts.
(Yes, we see both! Ugh.)

James Hunter Ross
Senior Software Developer
O'Neil Software, Inc.
(e-mail address removed)

 

[Robbe Morris [C# MVP]]

InProc is a problem with app recycles. You'll
play hell trying to prevent them entirely.

Looks like you need to hunt through your
classes and set them to be serializable.

Then, I'd seriously reviewing whether
everything you are storing in session
should be there.

Even if you make them serializable,
you may have a scalability problem just
waiting to say "hello" in production.

 

[JIMCO Software]

Regardless of your disagreement, application restarts
*will* occur, no matter which state management methods is used.

Sorry, Jim, you're just plain wrong on this one.

I'm not wrong. I work with major companies every single day using InProc
Session state and they don't experience app domain restarts. Unplanned app
domain restarts can (and should) absolutely be prevented.

James, there is significant overhead in moving to out of proc Session state.
However, if you do decide to go that route, choose State Server over SQL
Server. State Server is really just a service that emulates InProc Session
state and it's quite a bit more efficient. However, if I were in charge of
troubleshooting this, I would defininately find out why you are experiencing
these app domain restarts and fix it.

 

[JIMCO Software]

Thank you gentlemen!

We've got some homework to do now. Restarts will occur, now we need
to determine how often they are likely and what we can do to minimize
them. We are not in a position to avoid InProc because of legacy
backend issues. We are guessing that maybe good old fashioned bugs
in our own ASP.NET code might be contributing to the frequency of
process and application restarts. (Yes, we see both! Ugh.)

James,

Call Microsoft. They can assist you a great deal here. If the process is
restarting, a dump analysis can provide the details on root cause.

 

[James Hunter Ross]

Hi Robbe,

I don't know if we are abusing Session... but, we do interface with a legacy
unmanaged API. This API establishes the actual database connection, manages
result sets, etc. Our ASP.NET "Session" really doesn't hold too much, BUT
the database connection itself does. The contents of temp tables owned by
the DB connection is critically important to our app functionality. If our
Session goes away, we must let the DB connection go too, and so we lose temp
tables, and everything they represent. Even if we use the State Server or
SQL Server to persist the ASP.NET Session, our DB connection will be gone,
and with it the real important state stuff.

So even though I don't think we *abuse* Session, I think our app is too
vulnerable to application (or w3wp.exe process) restarts. For this reason
we are trying to minimize restarts, then we can assess whether the problem
is great enough to warrant some re-architecting. (We would need to divorce
ASP.NET Session from DB connection so that a DB connecion could persist
independently of restarts; the ASP.NET stuff would need to make API calls
across processes to some new "OurAppDbConnection Service", and all of this
would be quite a project, though perhaps ultimately inevitable.)

As always, I really appreciate your words and input! Perhaps I'll be of
service at some point.

James

 

[Juan T. Llibre]

re:

I'm not wrong. I work with major companies every single day using InProc Session state
and they don't experience app domain restarts. Unplanned app domain restarts can (and
should) absolutely be prevented.

I'd like to see an outline of how that can be accomplished.

 

[JIMCO Software]

re:

I'd like to see an outline of how that can be accomplished.

Well, I would first start by outlining those things that can cause unplanned
app domain restarts:

1. File Change Notifications
2. Process model / App Pool configuration
3. Process termination for reasons of latency (or genuine deadlock),
crashes, number 2, or user initiated

All three of those can be avoided. This is not theory. I am speaking from
a great deal of experience in this area.

 

[Juan T. Llibre]

re:

2. Process model / App Pool configuration
All three of those can be avoided. This is not theory. I am speaking from a great deal
of experience in this area.

Can you show how unplanned app restarts can be avoided ?

In particular, how do you avoid app restarts due to limits on maximum
memory utilization; the recycling of worker processes in minutes; and the
recycling of worker processes due to the limit on the kernel request queue.

If you don't set any of those, how do you avoid memory bottlenecks
which could lead to IIS being locked due to RAM constraints ?

The whole *purpose* of application recycling is to avoid RAM problems.

How do you avoid those problems if you don't
manage memory utilization by restarting applications ?

 

[JIMCO Software]

re:

In particular, how do you avoid app restarts due to limits on maximum
memory utilization; the recycling of worker processes in minutes; and
the recycling of worker processes due to the limit on the kernel
request queue.

If you are recycling due to memory limits, you need to address your memory
usage.

If you are recycling due to process model or app pool configuration and you
don't want to recycle, change your configuration.

If you are recycling because you are queueing requests, fix that problem by
either adjusting the thread pool or throwing more resources at your app.

The whole *purpose* of application recycling is to avoid RAM problems.

Well, that's ONE of the purposes. I certainly wouldn't say it is the whole
purpose.

I think what you are prescribing is that if you have problems with your app,
just let it recycle regularly to start fresh. In my opinion, that's a bad
approach. If I were to recommend that to a major US company, I think they
wouldn't be too pleased!