Timeout period not seeming to work correctly

[tshad]

I have the following in my web.config in my application root.

<forms name="staffing"
loginUrl="/applicant/EELogin.aspx"
timeout="400"
protection="All"
path="/" />

I assumed this meant the session would be valid for 400 minutes. Is this
correct?

I seem to find my session cookies gone after about 20-30 minutes, however.

Do I have to do something else to make this timeout longer?

Also, when is the timeout refreshed?

On each new page or on each postback?

What about refreshing a page?

Thanks,

Tom

 

[Brock Allen]

It's possible that the worker process is restarting, thus losing your in
memory Session STate. I'd suggest looking into configuring the NTState service.
This will show you how to set that up:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp12282000.asp

-Brock
DevelopMentor
http://staff.develop.com/ballen

 

[Hans Kesting]

I have the following in my web.config in my application root.

<forms name="staffing"
loginUrl="/applicant/EELogin.aspx"
timeout="400"
protection="All"
path="/" />

I assumed this meant the session would be valid for 400 minutes. Is
this correct?

I seem to find my session cookies gone after about 20-30 minutes,
however.
Do I have to do something else to make this timeout longer?

Also, when is the timeout refreshed?

On each new page or on each postback?

What about refreshing a page?

Thanks,

Tom

If I'm not mistaken, the login-timeout is *different* from the session timeout.
So the login might be valid for 400 minutes (no experience with that, so I don't
know for sure), but the session still times out after 20 minutes.

See web.config, <sessionState ... timeout="20" /> for the session timeout.

Hans Kesting

 

[tshad]

If I'm not mistaken, the login-timeout is *different* from the session
timeout.
So the login might be valid for 400 minutes (no experience with that, so I
don't
know for sure), but the session still times out after 20 minutes.

See web.config, <sessionState ... timeout="20" /> for the session timeout.

Makes sense, but when I tried it, it broke my web.config file.

I added in:

<sessionstate
mode="inproc"
cookieless="false"
timeout="400"
/>

Now I get the error:

***************************************************************************************
Runtime Error
Description: An application error occurred on the server. The current custom
error settings for this application prevent the details of the application
error from being viewed remotely (for security reasons). It could, however,
be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable
on remote machines, please create a <customErrors> tag within a "web.config"
configuration file located in the root directory of the current web
application. This <customErrors> tag should then have its "mode" attribute
set to "Off".

<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>

******************************************************************************************

But I have the customErrors tag in my web.config and it works fine until I
add the SessionState section.

Top part of my web.config
************************************************************************
<configuration>
<system.web>
<customErrors mode="Off"/>
<authentication mode="Forms">
<forms name="staffing"
loginUrl="/applicant/EELogin.aspx"
timeout="400"
protection="All"
path="/" />
</authentication>
*************************************************************************

Tom

 

[Ronald Lemmen]

You are probably getting the error because the web.config is
casesensitive. That means that you should not enter sessionstate, but
use sessionState instead.

Hope this helps,

Ronald Lemmen

 

[tshad]

You are probably getting the error because the web.config is
casesensitive. That means that you should not enter sessionstate, but
use sessionState instead.

That was it.

I also had to use "InProc" instead of "inproc".

I never could figure out what the problem was and was going to come back to
it later.

Thanks,

Tom

 

[tshad]

I am still having the problem even with the fixes below.

The first part of my web.config is:

<configuration>
<system.web>
<customErrors mode="Off"/>
<sessionState
mode="InProc"
cookieless="false"
timeout="400"
/>
<authentication mode="Forms">
<forms name="staffing"
loginUrl="/applicant/EELogin.aspx"
timeout="400"
protection="All"
path="/" />
</authentication>

I have both forms and sessionState to timeout at 400 minutes.

The problem is that after about 20-30 minutes of just going back and forth
using the same page (as I am testing the page), all of a sudden all my
session variables are gone. They shouldn't be gone for hours.

What else am I missing?

I need to figure this out as we are going to be showing this to some people
and I don't want the page timing in 20 minutes.

Thanks,

Tom

 

[Juan T. Llibre]

You might want to take a look at the setting
for recycling the ASP.NET worker process.

When you use InProc session state management,
and the worker process recycles, your application
restarts, causing the loss of all your session variables,
if you're using InProc state management.

Open the IIS MMC, and scroll down to Application Pools.
Check the recycling settings for short recycle periods and adjust if necessary.

You might also want to consider using State Server or SQL Server
State management, instead of InProc, since they persist Session
settings when the ASP.NET worker processes are recycled.



Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

 

[tshad]

You might want to take a look at the setting
for recycling the ASP.NET worker process.

When you use InProc session state management,
and the worker process recycles, your application
restarts, causing the loss of all your session variables,
if you're using InProc state management.

Open the IIS MMC, and scroll down to Application Pools.
Check the recycling settings for short recycle periods and adjust if
necessary.

I assume you are talking about the Idle timeout (as that was set for 20
minutes).

What is the drawback of having it for an hour? Does it slow things down or
leave the session variables around for longer than necessary?

You might also want to consider using State Server or SQL Server
State management, instead of InProc, since they persist Session
settings when the ASP.NET worker processes are recycled.

I need to check out the pluses and minuses of these to decide which is best
for us.

I assume that InProc is default?

Thanks,

Tom

 

[tshad]

I assume you are talking about the Idle timeout (as that was set for 20
minutes).

What is the drawback of having it for an hour? Does it slow things down
or leave the session variables around for longer than necessary?

When the worker process recycles, you say you lose your Session variables,
do you also lose your ASP.NET_SessionId ? I found that if reset the web
server, I would lose my session variables, but not my ASP.NET_SessionId.

Also, does the Session_End event fire when the worker process recycles?

I know it does when you abandon it.

Thanks,

Tom