ASP.NET 会话丢失，但仅针对一个特定用户
我有一个 ASP.NET 应用程序在两台负载平衡服务器上运行。除了一组客户外，一切正常。所有这些客户都来自同一家公司。随机抛出未处理的 NullReferenceException 错误。它在随机的时间、随机的地点发生。会议似乎完全消失了。由于这种情况只发生在特定的用户组中，我必须假设这与他们的环境有关。我见过用户使用 IE6、IE7、IE8 和 FF 进入，并且在所有情况下都会出现错误。
我不是 100% 确定如何解决这个问题。有人有什么想法吗？
编辑：会话设置为“InProc”
<sessionState mode="InProc" cookieless="false" timeout="20" />
I have an ASP.NET application that is running on two load balanced servers. Everything is working fine except for one group of customers. All of these customers are coming from the same company. Randomly, an unhandled NullReferenceException error is thrown. It happens at random times in random places. It seems as if the session is just totally gone. since this is only happening for a specific group of users I have to assume that is has something to do with thier environment. I have seen users coming in with IE6, IE7, IE8 and FF and it the error occurs in all cases.
I am not 100% sure how to troubleshoot this. Does anyone have any ideas?
EDIT: Session is set to "InProc"
<sessionState mode="InProc" cookieless="false" timeout="20" />
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
InProc 会话不在服务器之间共享，因此听起来这组用户正在从一台服务器移动到另一台服务器，而其他用户则没有。也许您的负载均衡器正在尝试使用 IP 地址或其他内容来实现粘性会话，而该组织正在阻止该信息。
InProc session isn't shared between servers, so it sounds like this group of users is moving from one server to another and the others aren't. Maybe your load balancer is trying to achieve sticky sessions using something like IP address or whatever and this organisation is blocking that information.
我联系了遇到问题的用户。我让他打开浏览器并访问whatsmyip.org，并告诉我上面显示的是他的IP 地址。然后我让他刷新几次屏幕。好吧，你难道不知道吗，IP 地址已经改变了。它不断在两个不同的IP地址之间切换。这不是他机器的 IP 地址，而是两个不同代理的 IP 地址。显然，每个请求都可能来自其中一个。
我们的负载均衡器（称为 Zeus 的东西 - 我不是网络专家）被设置为使用 IP 地址建立会话关联（又名粘性连接）。我们更改了设置，以便负载均衡器会删除 cookie 并使用它来维护会话，现在一切正常。
I got in contact with the user that was having the porblem. I asked him to open a browser and go to whatsmyip.org and tell me what it says is his IP address. Then I asked him to refresh the screen a few times. Well, wouldn't you know it, the IP address changed. It kept switching between two different IP addresses. This was not the IP address of his machine but of two different proxies. Each request could come form one or the other apparently.
Our load balancer (something called Zeus - I am not a network guy) was set to estabilsh session affinity (a.k.a. sticky connections) using IP addresses. We changed the settings so that the load balancer would drop a cookie and use that to maintain the session and everything works correctly now.
如果您使用 SQL 来存储会话状态，请检查场中的所有服务器是否都在查看相同的 SQL 数据库 - 我之前就遇到过这个问题，花了相当长的时间才解决这个问题！
编辑：
实际上，当您在网络场中运行时，您可能需要将其设置为 StateServer。
请参阅 MSDN 中有关会话状态模式的内容。
If you're using SQL to store session state, check that all the servers in the farm are looking at the same SQL database - I've been caught out by this one before and it took quite a while to work it out!
Edit:
Actually you might need to set it to
StateServeras you're running in a web farm.See this about Session-State Modes from MSDN.
如果您的负载平衡基于将每次访问定向到最不繁忙的服务器，那么 InProc 将无法工作。您需要使用 StateServer 或 SQLServer 模式。
想象一下，来自客户端的第一次点击定向到服务器 A - 在服务器 A 上启动一个新会话。来自同一客户端的第二次点击可能会发送到服务器 B，提供来自服务器 A 的会话 cookie，但服务器 B 无法识别。
如果您有“粘性”（或客户端亲和性）负载平衡，其中第一次命中分配给最不繁忙的服务器，但随后来自同一会话的后续命中被定向到同一服务器，则 InProc 应该仍然可以工作。
If your load balancing is based on directing every hit to the least-busy server, then InProc isn't going to work. you would need to use StateServer or SQLServer modes.
Imagine the first hit from a client is directed to server A - that starts a new session on server A. The second hit from the same client could go to server B, supplying the session cookie from server A which server B doesn't recognise.
If you have 'sticky' (or client affinity) load balancing, where the first hit is allocated to the least-busy server, but then subsequent hits from the same session are directed to the same server, then InProc should still work.