2011-08-24 69 views
6

我们看到,在加载情况下会话数据被破坏或丢失,但会话本身仍然存在。ASP.NET会话已损坏加载

我们的网站托管在运行ASP.Net 4.0的IIS 7上,并且在Web服务器场中使用InProc会话状态,并在Cisco ACE Appliance负载均衡器后面共有4台服务器。

此时问题是随机的,我们不能随意重现问题。这个网络应用程序在过去七个月里一直运行正常。

我们认识到,即使正在使用粘性会话,Microsoft也不建议将InProc与Web场一起使用。

我们确实有一个实验室环境,与我们的生产环境合理相同,但无法在实质负载下重现(我们使用WAPT)。

在我们的生产环境中,我们试图在负载平衡器后面隔离一个服务器,以消除负载平衡器本身造成的“服务器跳跃”。但是,即使在一台服务器上运行,问题仍然存在。我们在生产中看不到任何AppPool或IIS回收。作为标准做法,我们每天在美国东部时间凌晨3点回收生产应用程序池,并且在操作系统上享有数月的正常运行时间。

会话中存储的内容包括从简单类型(整数和字符串)到整个购物车(复杂对象图)甚至用户控件(.ascx)实例的各种对象。由于无法轻松对这些对象中的很多对象进行序列化,因此我们无法在合理的时间段内切换到进程外会话存储。

有人建议尝试使用Fiddler捕获HTTP会话。运行Fiddler的问题是我们不能有意地自行重现问题。所以,这使我们无法捕获发生故障事件的HTTP跟踪。我们实验室的WAPT跟踪记录可能会提供与Fiddler相同的数据,但正如我所说的,我们不能在那里复制它。

我会非常感谢任何见解的人可能有...基于所有的迄今这里收集的信息

+0

你有关于哪个会话数据被破坏的信息吗?它是购物车吗?它是随机的吗?你怎么知道你是否无法重现它?而且,我确信你之前听说过这个,所以我可能听起来像是一个破损的记录,你可能想要做一些关于需要在会话中存储用户购物车的整个对象图并存储用户控制实例。 – Sumo

+0

我们知道即使我们无法复制它,因为我们收到带有堆栈跟踪的电子邮件时发生,与客户呼叫巧合。它通常是随机值,但特别是似乎正在丢弃,它来自包含访问此会话变量的共享只读属性。这是非常随机的,但肯定发生在负载下,因为我的客户服务人员直到应用程序池启动后经过一段时间才开始接受投诉。是的,我们知道我们需要将该淫秽对象图和用户控制权排除在会话之外,但该修复程序距离几周。 :/ –

+0

你能发布关于这个共享变量的更多细节吗? – Sumo

回答

1

,我会用一个猜测回答,因为该问题是什么。

该会话可能以某种方式到期。

应用程序池回收不是唯一会导致会话过期的事情。而且,作为Hanselman will tell you,当您将InProc会话管理和高容量结合使用时,这是一种常见现象。

编辑:看看一个older blog post for IIS6,详细说明如何确定丢失的会话这样的,特别是影响特定用户,而不仅仅是所有会话的人的原因,因为这可能发生了。感兴趣的部分就在关于Web Gardens的Application_End代码片段之后。我查找了一条类似于此的更新信息,我真的可以找到的所有问题都是answer to another question here on SO