session state variables expiring too quickly

[bennett]

In the web.config file for my application, in the <sessionState>
section I have set timeout="120" (in minutes), but session state
variables in my application seem to be expiring in about 5 minutes.
Any idea what could cause this?

I have the mode="InProc" attribute set for <sessionState>. I know that
some people have solved the problem of session variables timing out too
quickly by changing that attribute, but I cannot use mode="StateServer"
because my ASP.Net host doesn't support running a state server on the
shared host, and I can't use mode="SQLServer" because I don't have the
admin rights on my host's SQL Server to set up the SQL Server session
state database. (I tried running the InstallSqlState.sql script on my
host's SQL Server database and got a bunch of access denied errors.)

I realize this can happen occasionally if the server is rebooted or
ASP.Net is restarted, but with my host's server it's consistent; the
values *always* die within five minutes. One thread at
http://www.gotdotnet.com/Community/MessageBoard/Thread.aspx?id=17380
suggested that sporadic dying of session state variables might have
something to do with an anti-virus program running on the host, but in
my case it happens every time.

I'm developing the app on my local IIS Web server and then using Visual
Studio's Project->Copy Project function to copy the project to the
remote host. When the application runs on my local machine, the
session variables do not time out in 5 minutes, but when it's copied to
the remote server, they do. This leads me to think it's not something
in the project files but some configuration setting in IIS, but the
question is, what? More importantly, is there something I can change
in my project to make session state variables last longer in all cases,
independent of whatever IIS setting is breaking it?

My host says that in the Properties for my web site in IIS, they have
the HTTP "Connection timeout" set to 120 (expressed in seconds; the
default is 900). (This is not the same as the session timeout
setting.) Could that have anything to do with it? But I tried setting
connection timeout to 120 on my local IIS and my local application's
session vars still didn't die after 5 minutes. (I wouldn't expect the
Connection timeout to have anything to do with it anyway, because I
thought ASP.Net uses cookies -- or query strings in the case of
cookie-less sessions -- to associate your browser with your current
session, and that will work even if the HTTP connection dies, as long
as your session hasn't expired on the server yet. Wouldn't it?)

Any help would be extremely appreciated,

-Bennett

 

[Kevin Spencer]

Hi Bennett,

I would agree that the problem lies on your hosted server, and with its
configuration somehow. Of course, the hosted web server is a black box to
you, but not to the network administrators on your hosted server. Rather
than trying to circumvent an unknown issue, I would recommend communicating
with the support personnel on your hosting service. Yes, I know that this is
likely to be a pain in the butt, as you will probably have to work your way
up the food chain until you get someone with some real technical knowledge
Perhaps it would help to think of the process as giving entry-level wannabes
some real problem-solving experience, or at least convincing some of them
that they should go into another line of work.

At any rate, somewhere on that hosting service is a real network admin, who
knows how the .Net platform works, and how it affects their network, as well
as what sort of configuration they have, and how it might affect hosted
ASP.Net apps. Or, you're hosting with some fly-by-night hosting service that
can't think their way out of a paper bag, in which case you will find that
out and in the process, find a decent hosting service somewhere else!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[bennett]

Actually that did work. Turns out they automatically cycle any
application on their server that's idle for more than five minutes, and
as I was the only person using this particular app while I was testing
it, that's what was happening. I got them to up the idle time to 20
minutes and I have a scheduled job that hits a script on the site every
15 minutes now to stop it from idling out at all, and now it is able to
maintain session variables for at least 1.5 hours (when I have the
sessionState timeout set to 120 minutes in web.config). Thanks!

 

[Juan T. Llibre]

Check your <processModel responseDeadlockInterval setting
and set a maximum value that is at least the same as your longest
application-level timeout setting.

responseDeadlockInterval="hrs:mins:secs|Infinite"

In your case, that would be :

responseDeadlockInterval="2:00:00"
since you have set your session timeout for 120 minutes.

This may not be the specific solution for your p[roblem,
but it may be one less thing to worry about, and it doesn't
cost you anything to try it.

When the ASP.NET worker process has been idle for the duration that is
specified in the responseDeadlockInterval configuration setting, it causes
the deadlock detection mechanism to restart the worker process, losing your
session data if you're running sessionState Inproc.