丢失会话变量 - 什么异常可能会导致会话丢失?

发布于 2024-09-26 04:32:22 字数 2293 浏览 1 评论 0原文

我在生产系统(asp.net webforms .net 4)上启用了运行状况监控,并且我发现有很多错误发送给我,表明会话变量已丢失。

(我试图将会话状态之外的某些内容附加到实体框架数据上下文,并收到“值不能为空,参数名称实体”错误)。因此,不知何故,会话变量现在包含 null 而不是对象。

有趣的是,我们将相同的应用程序部署在两台独立的服务器上 - 一台用于外部用户的 DMZ 服务器和一台用于内部用户的内部服务器。两个不同服务器上的这两个应用程序似乎都存在相同的问题。

运行状况监控还监控生命周期事件,我可以从中看到,我们没有发生 IIS 回收、配置更改、bin 文件夹更改、重新编译等情况。

我已阅读此页面: http://weblogs.asp.net/bleroy/archive/2004/08/03/Don_2700_t-redirect-after-setting-a-Session-variable-_2800_or-do- it-right_2900_.aspx

我可以确认这不是 Response.Redirect 问题,因为这没有发生 - 这是一个在线申请表 - 它将一个对象置于 page_load 上的会话状态,并且有一个多视图 - 当“下一步”时按下后,对象退出会话状态,附加到数据上下文,从 Web 表单进行更改并更新数据上下文。所以没有发生response.redirect。

我还可以确认该链接中的“更新 1”和“更新 2”中的详细信息与我无关 - 应用程序池中只有 1 个工作进程正在运行,并且服务器名称或网址不包含下划线。

我还怀疑发生会话超时的可能性,但它们应该由正在运行的其他代码来处理以检测会话超时(请参阅:http://blogs.msdn.com/b/nikhiln/archive/2007/ 06/21/Detecting-session-timeout-in-asp-net-2-0-web-applications.aspx )我已经反复测试过 - 部分问题是我自己无法重现此错误。

所以:-
- 没有超时
- 不是 IIS 工作进程回收或任何其他会生成运行状况监控生命周期事件的事物
- 不使用response.redirect
- 没有网络场/多个工作进程

然后我找到了这个线程: http ://bytes.com/topic/asp-net/answers/490975-disappearing-sessions,其中 MVP 说了以下内容:

任何时候 IIS 应用程序 重新启动,所有会话都重新启动 也。所以是的,这通常会 发生在重新编译期间和一些 主要未处理的应用程序级别 例外。

但遗憾的是没有详细说明哪种“主要的未处理的应用程序级别异常”可能会导致会话丢失 - 这是一个全新的系统,我们仍然有未处理的异常,我们正在努力修复 - 所以我们在这里讨论的是哪种例外?一个人的会话中的应用程序异常真的会删除该应用程序持有的所有会话吗?

该线程也涉及它: http://bytes.com/topic/ asp-net/answers/490975-disappearing-sessions

我见过的唯一相似的是 当运行时错误发生时 ASP.NET 应用程序,导致 应用程序重新启动。你是 接收Application_OnStart事件 也是吗?

所以我猜测如果我有一个运行时错误导致应用程序重新启动,那也会生成一个运行状况监控生命周期事件,对吧?我只是没有得到任何这些......

如果我真的可以重现这个会容易得多,但我就是不能!

无论如何,很抱歉问了一个冗长的问题,只是希望有人有一些想法。

问候

I have health monitoring enabled on a production system (asp.net webforms .net 4) and I see that there's a lot of errors being sent to me indicating that a session variable has been lost.

(I am trying to attach something out of session state to a entity framework data context and get a "Value cannot be null, parameter name entity" error). So somehow the session variable now contains null and not an object.

Interestingly we have the same application deployed on two separate servers - one DMZ server for external users and one internal server for internal users. Both of these applications on two different servers seem to have the same problem.

Health Monitoring is also monitoring lifetime events and I can see from this that we do not have something like IIS recycling, config changes, changes to bin folder, recompilations etc, occuring.

I've read this page: http://weblogs.asp.net/bleroy/archive/2004/08/03/Don_2700_t-redirect-after-setting-a-Session-variable-_2800_or-do-it-right_2900_.aspx

I can confirm that it's not a Response.Redirect problem because that's not happening - this is an online application form - it puts an object in session state on page_load and there's a multiview - when "next" is pressed, the object comes out of session state, is attached to the data context, changes are made from the web form and the datacontext updated. So there's no response.redirect happening.

I can also confirm the details in "Update 1" and "Update 2" from that link are not relevant to me - there is only 1 worker process running in the application pool and the server name or web address do not contain underscores.

I also persued the possibility of session timeouts occuring but they should be handled by other code which is running to detect session timeouts (see: http://blogs.msdn.com/b/nikhiln/archive/2007/06/21/detecting-session-timeout-in-asp-net-2-0-web-applications.aspx ) which I have tested over and over - Part of the problem is I just cannot reproduce this error myself.

So:-
- Not timeouts
- Not the IIS worker process recycling or any other thing which would generate a Health Monitoring lifetime event
- Not using response.redirect
- Not got a web farm/multiple worker processes

I then found this thread: http://bytes.com/topic/asp-net/answers/490975-disappearing-sessions where an MVP said the following:

Anytime the IIS application is
restarted, all sessions are restarted
too. So yes, this would generally
happen during recompilations and some
major unhandled application level
exceptions.

But sadly didn't elaborate what sort of "major unhandled application level exceptions" might lead to session loss - this is a brand new system and we do still have unhandled exeptions that we're working on fixing - so what sort of exceptions are we talking about here? Can an application exception in one person's session really delete all sessions held by the application?

This thread also touches on it: http://bytes.com/topic/asp-net/answers/490975-disappearing-sessions

The only thing I've seen similar is
when a runtime error occurs in the
ASP.NET application, causing the
application to restart. Are you
receiving Application_OnStart events
too?

So I'm guessing if I had a runtime error that caused the application to restart, that would also generate a health monitoring lifetime event, right? And I'm just not getting any of those...

It would be a lot easier if I could actually repro this but I just cannot!

Anyway sorry for a long rambly question, just hope somebody has some ideas.

Regards

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

飘然心甜 2024-10-03 04:32:22

您是否考虑过将会话状态放置在应用程序之外,例如使用任何 asp.net out会话状态的进程模式

默认情况下,会话状态在您的应用程序内维护。它不能跨多个服务器使用,也不能跨应用程序崩溃(即应用程序中任何未处理的异常)进行维护。

  1. 使用 SQL Server 模式使相同的会话状态跨多个服务器可用。

  2. 或者,如果您的负载均衡器保证强会话亲和力,则可以使用 asp.net 状态服务器来管理每个服务器中的状态,使状态在应用程序重新启动后仍然存在。

Did you consider placing session state outside the app, e.g. with any of the asp.net out-of-process modes for session state?

By default, session state is maintained inside your app. It is not available across multiple servers, nor is it maintained across application crashes (i.e. any unhandled exceptions in your app.)

  1. Use the SQL Server mode to make the same session state available across multiple servers.

  2. Alternatively, if your load balancer guaranties strong session affinity, you can use the asp.net state server to manage state in each server in a way that lets state survive application restarts.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文