I am hosting an MVC site (.NET Framework 4.5) on IIS 7.5. Rather than using session variables, I've created a static module to hold my site-wide variables and methods:
Public Module CurrentSurveySession
Public Property curSurveyTakerID As Integer
Public Property curSurveyTakerSurveys As List(Of SurveyAndOptionViewModel)
Public Property curSurveyTypeID As Integer
Public Property curSurveyInstanceID As Integer
Public Property curSurveyTotalCtgs As Integer
Public Property curSurveyCurrentCtgIdx As Integer
Public Property curSurveyErrorMessage As String
...
Public Sub AddSurveyAndOption(ByRef so As SurveyAndOptionViewModel)
curSurveyTakerSurveys.Add(so)
End Sub
...
End Module
The IIS Application Pool for the site is configured to recycle every 1740 minutes. The website ASP.net Session State has a cookie time-out of 1440 minutes. (The Default web site is set for 20 mins time-out but I would think the specific site setting overrides
this).
So I'm not sure why the time-out is occurring. I encounter a NullReference exception whenever the value of one or more static variables is needed because they are no longer available. Everything works fine if interactions don't lapse more than 20 minutes,
however.
Your sharing a single instance of CurrentSurveySession with every user on the site. If a user changes one of the properties the property is changed for all users on the site. Are you sure that's what you want? Session is scoped to the user which is very
different than using a module.
Generally, global application values are stored in the web.config.
That's a good point! I am preparing this application in the test environment using the singleton pattern so it makes sense for one user at a time. But in order to scale it, I imagine I have few option besides converting the module into a regular class and
storing it within the SessionState. I was, however curious why the static variables were being abandoned within minutes (i.e. a misconfiguration on my part with IIS settings, etc.).
That's a good point! I am preparing this application in the test environment using the singleton pattern so it makes sense for one user at a time. But in order to scale it, I imagine I have few option besides converting the module into a regular class and storing
it within the SessionState.
It is not an issue of scale but of concurrency. In order for the singleton to work you'll need to scope the singleton to the current request or user. This is just an extra layer of complexity and easily made simple (and scalable) by taking advantage of
client persistence (cookie) or a database.
kj27
I was, however curious why the static variables were being abandoned within minutes (i.e. a misconfiguration on my part with IIS settings, etc.).
Can't answer that without seeing the code or knowing the IIS configuration.
Static object exist in memory. I assume either the variables are being overwritten or for some reason memory is cleared.
IIS application pools go idle after 20 minutes (default) unless you changed this value.
The scaling I'm referring to is indeed related to concurrency - instead of the test application just being limited to one user (for which the current static setup would be sufficient), you would be scaling to multiple (concurrent) users. So I could theoretically
convert the current module into a class and then store that in the session state to make it user specific.
The IIS site (as mentioned) is set to time-out in 1440 minutes. That site, however resides under the "Default Web Site" which is set to 20 minutes (as you mention, the default). In the past, extending the time-out at the specific site level seemed to over-ride
the default web site's 20 minute setting. But in the past, I was relying on the session state exclusively. I was wondering why this didn't work for static variables. I would agree that memory clearing is definitely an issue and the fact that it happens < 30
mins is not a coincidence.
The scaling I'm referring to is indeed related to concurrency - instead of the test application just being limited to one user (for which the current static setup would be sufficient), you would be scaling to multiple (concurrent) users. So I could theoretically
convert the current module into a class and then store that in the session state to make it user specific.
No, you created a bug. Web applications by definition are concurrent applications. Do not use Session if you want the app to scale. Session is stored in server memory so your are limited to a single server.
kj27
The IIS site (as mentioned) is set to time-out in 1440 minutes. That site, however resides under the "Default Web Site" which is set to 20 minutes (as you mention, the default). In the past, extending the time-out at the specific site level seemed to over-ride
the default web site's 20 minute setting. But in the past, I was relying on the session state exclusively. I was wondering why this didn't work for static variables. I would agree that memory clearing is definitely an issue and the fact that it happens < 30
mins is not a coincidence.
Session TO has nothing to do with idle timeout and Session TO would not affect static variables.
With all due respect, it was not a bug if it was a test application designed for a single user. If my user happens to be located remotely, the most effective way I can administer the application to him/her is via a web or mobile platform. If concurrency
is desired, then surely sessionstate is the effective mechanism (which of course has a client as well as server component, if we're depending on cookies).
The reason I mention timeout is because you had brought it up in the previous post. I had mentioned time-outs as well as app pool recycling time. Again with all due respect, I would disagree with the notion of session not being connected to time-outs. IIS
manager lists timeout under ASP.Net session so clearly they are connected. If after 20 minutes, the server is deleting/purging session info. then the client supplied cookie has no relevance.
UPDATE: As an aid to anyone facing the same issue - the problem turned out to be the Idle Time-out value for the app pool. Updating this value seemed to resolve the issue. Best Regards.
Again - thanks for your input. Please consider this matter closed.
Member
12 Points
72 Posts
Static variable unavailability after inactivity
Aug 28, 2017 02:23 PM|kj27|LINK
Hi there,
I am hosting an MVC site (.NET Framework 4.5) on IIS 7.5. Rather than using session variables, I've created a static module to hold my site-wide variables and methods:
Public Module CurrentSurveySession Public Property curSurveyTakerID As Integer Public Property curSurveyTakerSurveys As List(Of SurveyAndOptionViewModel) Public Property curSurveyTypeID As Integer Public Property curSurveyInstanceID As Integer Public Property curSurveyTotalCtgs As Integer Public Property curSurveyCurrentCtgIdx As Integer Public Property curSurveyErrorMessage As String ... Public Sub AddSurveyAndOption(ByRef so As SurveyAndOptionViewModel) curSurveyTakerSurveys.Add(so) End Sub ... End ModuleThe IIS Application Pool for the site is configured to recycle every 1740 minutes. The website ASP.net Session State has a cookie time-out of 1440 minutes. (The Default web site is set for 20 mins time-out but I would think the specific site setting overrides this).
So I'm not sure why the time-out is occurring. I encounter a NullReference exception whenever the value of one or more static variables is needed because they are no longer available. Everything works fine if interactions don't lapse more than 20 minutes, however.
All-Star
53781 Points
24076 Posts
Re: Static variable unavailability after inactivity
Aug 28, 2017 02:50 PM|mgebhard|LINK
Your sharing a single instance of CurrentSurveySession with every user on the site. If a user changes one of the properties the property is changed for all users on the site. Are you sure that's what you want? Session is scoped to the user which is very different than using a module.
Generally, global application values are stored in the web.config.
Member
12 Points
72 Posts
Re: Static variable unavailability after inactivity
Aug 28, 2017 03:54 PM|kj27|LINK
That's a good point! I am preparing this application in the test environment using the singleton pattern so it makes sense for one user at a time. But in order to scale it, I imagine I have few option besides converting the module into a regular class and storing it within the SessionState. I was, however curious why the static variables were being abandoned within minutes (i.e. a misconfiguration on my part with IIS settings, etc.).
All-Star
53781 Points
24076 Posts
Re: Static variable unavailability after inactivity
Aug 28, 2017 04:13 PM|mgebhard|LINK
It is not an issue of scale but of concurrency. In order for the singleton to work you'll need to scope the singleton to the current request or user. This is just an extra layer of complexity and easily made simple (and scalable) by taking advantage of client persistence (cookie) or a database.
Can't answer that without seeing the code or knowing the IIS configuration.
Static object exist in memory. I assume either the variables are being overwritten or for some reason memory is cleared.
IIS application pools go idle after 20 minutes (default) unless you changed this value.
https://technet.microsoft.com/en-us/library/cc771956(v=ws.10).aspx
Member
12 Points
72 Posts
Re: Static variable unavailability after inactivity
Aug 28, 2017 04:25 PM|kj27|LINK
The scaling I'm referring to is indeed related to concurrency - instead of the test application just being limited to one user (for which the current static setup would be sufficient), you would be scaling to multiple (concurrent) users. So I could theoretically convert the current module into a class and then store that in the session state to make it user specific.
The IIS site (as mentioned) is set to time-out in 1440 minutes. That site, however resides under the "Default Web Site" which is set to 20 minutes (as you mention, the default). In the past, extending the time-out at the specific site level seemed to over-ride the default web site's 20 minute setting. But in the past, I was relying on the session state exclusively. I was wondering why this didn't work for static variables. I would agree that memory clearing is definitely an issue and the fact that it happens < 30 mins is not a coincidence.
Thanks for your help.
All-Star
53781 Points
24076 Posts
Re: Static variable unavailability after inactivity
Aug 28, 2017 05:47 PM|mgebhard|LINK
No, you created a bug. Web applications by definition are concurrent applications. Do not use Session if you want the app to scale. Session is stored in server memory so your are limited to a single server.
Session TO has nothing to do with idle timeout and Session TO would not affect static variables.
Member
12 Points
72 Posts
Re: Static variable unavailability after inactivity
Aug 28, 2017 07:47 PM|kj27|LINK
With all due respect, it was not a bug if it was a test application designed for a single user. If my user happens to be located remotely, the most effective way I can administer the application to him/her is via a web or mobile platform. If concurrency is desired, then surely sessionstate is the effective mechanism (which of course has a client as well as server component, if we're depending on cookies).
The reason I mention timeout is because you had brought it up in the previous post. I had mentioned time-outs as well as app pool recycling time. Again with all due respect, I would disagree with the notion of session not being connected to time-outs. IIS manager lists timeout under ASP.Net session so clearly they are connected. If after 20 minutes, the server is deleting/purging session info. then the client supplied cookie has no relevance.
UPDATE: As an aid to anyone facing the same issue - the problem turned out to be the Idle Time-out value for the app pool. Updating this value seemed to resolve the issue. Best Regards.
Again - thanks for your input. Please consider this matter closed.