<httpRuntime requestValidationMode="2.0" waitChangeNotification="86400" maxWaitChangeNotification="86400" /> <compilation debug="False" strict="false" explicit="true" targetFramework="4.0" numRecompilesBeforeAppRestart="1000" />
我已将IIS设置为在凌晨3点重新启动应用程序池,以确保在人们忙于使用服务器时它不会重新启动.我正在事件日志中记录应用程序池重新启动,以确保我知道它何时发生.
Dim runtime As HttpRuntime = GetType(System.Web.HttpRuntime).InvokeMember("_theRuntime",BindingFlags.NonPublic Or BindingFlags.Static Or BindingFlags.GetField,Nothing,Nothing)
Dim shutDownMessage As String = runtime.GetType().InvokeMember("_shutDownMessage",BindingFlags.NonPublic Or BindingFlags.Instance Or BindingFlags.GetField,runtime,Nothing)
Dim shutDownStack As String = runtime.GetType().InvokeMember("_shutDownStack",Nothing)
Dim evtSource As String = "ASP.NET"
Dim log As New EventLog
log.Source = evtSource
log.WriteEntry(String.Format("_shutDownMessage={0}{2}_shutDownStack={1}",shutDownMessage,shutDownStack,vbCrLf & vbCrLf),EventLogEntryType.Warning)
应用程序池重新启动时,我会收到事件日志条目.
发生这些错误时,应用程序池不会重新启动.
当特定会话变量丢失时,同一用户的大多数其他会话变量仍然存在.此外,通常还有另外10-20个用户登录该站点时不会受到影响.
获取错误的用户将备份,再次浏览相同的页面,它将正常工作.
我在运行带有.NET 3.5 32位和4GB内存的IIS6的Windows Server 2003(32位)上遇到此问题.作为我们服务器升级的一部分大约一年前,我们得到了一个新的网络服务器 – 运行IIS的Windows Server 2008(64位) 7带16GB内存.我将网站升级到.NET 4.0 64位.在新机器上仍然存在相同的问题(通常每天1-3次 – 在一天中的随机时间).
由于它的随机特性,我无法在调试中实现它,但我相信它也会在我们的开发环境中随机发生.开发服务器实际上与生产服务器具有相同的规格.
这两个环境都是隔离的,并作为单个Web服务器运行,而不是Web场的一部分.
我想我可能会尝试实现一个状态服务器以退出InProc模式,但这只是在黑暗中的另一个刺.
除了尝试使用State Server之外,我还能做些什么来确定何时发生这种情况或阻止它？
解决方法
正如您所说,您正在使用InProc会话,并且可能会发生用户重定向到与存储该会话变量的服务器不同的服务器.
在这种情况下,你应该像你提到的那样进入proc会话(Session State Server)
如果你去国家服务器请记住下面只是为了防止任何其他问题：
Since the Stateserver combines the ASP.NET Session ID with the IIS
application path to create a unique key,sessions issued for one of
the five new webs could not be found when accessed through one of the
other webs which is obvIoUsly extremely unfortunate in a weighted
round robin load balanced web farm
http://www-jo.se/f.pfleger/session-lost
还要看一下这个记录器,了解该应用程序是否可以根据您的意愿进行回收：
http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx
