22

有时,我网站上的一些请求开始挂在 Session 模块的 RequestAcquireState 状态。当螺旋开始时,所有请求都超时,我们需要在受影响的服务器上重新启动 IIS。

我对它进行了很多调查,我得到的唯一结论是,当应用程序尝试访问存储在 Session 中的用户数据时,不知何故发生了死锁。

我能想到的解决此问题的唯一选择是减少或停止在我的应用程序中使用会话。这绝对是计划的一部分,但我们需要一段时间才能完成。

我们在负载平衡中运行 6 台具有 IIS 7.5 的机器,超出 proc StateServer 和服务器关联。

关于如何解决此问题或根本无需完全删除会话的任何提示?

IIS 挂起进程

4

4 回答 4

7

提供者和会话模块(IIS 会话模块)上都存在锁定机制。您可以开发自定义会话模块,但您仍然需要没有锁定的提供程序,或者您可以开发没有锁定的自定义提供程序,但您仍然需要 IIS 会话模块,并且在该级别实现并不那么简单。

解决方案是UnlockedStateProvider [aka Unlocked]

跟随白兔:P(查看演示项目,它解释了一切。)

于 2014-12-15T09:34:11.880 回答
6

答案是 Hotfix Rollup 2828841 for .NET Framework 4.5 ,这里有所有解释:

http://forums.asp.net/t/1888889.aspx/2/10?Question+regarding+a+possible+bug+within+NET+4+5

这里是下载链接

它适用于我在 IIS 7.5 Windows Server 2008 rs x64 、带有大量 ajax 请求的 asp.net Web 表单应用程序上。

于 2013-05-15T21:42:03.673 回答
5

我今天刚刚发现,如果您有一个长时间运行的请求(或者在我的情况下是一个无限循环),那么所有后续请求都将被锁定,因为默认情况下 ASP.NET 锁定会话。

因此,如果您的用户中有请求RequestAcquireState,请检查是否有请求ExecuteRequestHandler锁定会话,从而阻止其他请求启动。

这里有一个关于如何防止会话锁定的讨论。(基本上,将大部分页面创建为 Session-Read-Only,并尽可能少地修改会话。)

于 2014-06-11T15:51:51.317 回答
0

这些用户是否有可能还有另一个长时间运行的请求,而您看到的堆积如山的请求实际上是次要请求?默认情况下,ASP.NET 将锁定 Session 直到请求完成。如果第二个请求在第一个请求完成之前进入,它将不得不等待。如果您使用的是 MVC,则可以通过向控制器添加属性来更改此行为。

[会话状态(会话状态行为。只读)]

这使得 Session 只读,消除了允许处理后续请求的锁定行为。

于 2014-04-02T15:53:06.277 回答