session state variables expiring too quickly

Discussion in 'ASP .Net' started by bennett, Jun 2, 2005.

  1. bennett

    bennett Guest

    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
     
    bennett, Jun 2, 2005
    #1
    1. Advertisements

  2. 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.
     
    Kevin Spencer, Jun 2, 2005
    #2
    1. Advertisements

  3. bennett

    bennett Guest

    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!
     
    bennett, Jun 3, 2005
    #3
  4. 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.
     
    Juan T. Llibre, Jun 28, 2005
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.