SignalR连接挂起，30秒后调用客户端 [英] SignalR connection hangs, calls client ~30 seconds later

问题描述

我在MVC4网站上使用NuGet的最新 SignalR 。使用示例中心代码（或任何代码），我有点奇怪连接问题。一切都很好，SignalR进行协商调用并记录EventSource Connected并返回connectionid。当它使用任何传输进行 signalR / connect 请求时，问题就开始了。它返回带有正确标题的200响应，但连接挂起。如果被调用的hub方法在 Caller 或 Clients 上执行方法，则不会在浏览器中执行直到下一个请求或10-30秒后如果你坐下等待。这就像是卡在管道中的东西，被下一个请求或一些清理机制刷新。

I'm using the latest SignalR from NuGet in a MVC4 site. Using the sample hub code (or any code), I'm getting some weird connection problems. Everything loads fine, SignalR makes the negotiate call and logs "EventSource Connected" and returns connectionid. The problem starts when it makes the signalR/connect request with any transport. It returns a 200 response with the proper headers but the connection hangs open. If the called hub method executes a method on Caller or Clients, it does not get executed in the browser until the next request OR after 10-30 seconds later if you sit and wait. It's like something's stuck in the pipe and it gets flushed by the next request or some cleanup mechanism.

我为此做了一个干净的项目一个拥有自己的应用程序池的新网站。该问题仅在一台计算机上发生，并且仅在IIS7.5下发生。在IIS Express或Cassini下的同一台机器上运行的同一项目工作正常。大约一个月前我上一次工作时，这个项目运行良好。我尝试过不同的浏览器和不同的jQuery版本。我已经尝试重新启动整个机器并在fiddler / debugger中花了几个小时无济于事。

I made a clean project for this in a new website with its own app pool. The issue occurs only on one machine and only under IIS7.5. The same project run on the same machine under IIS Express or Cassini works fine. This project ran fine the last time I worked on it about a month ago. I've tried different browsers and different jQuery versions. I've tried restarting the entire machine and spent several hours in fiddler/debugger to no avail.

这是测试运行的服务器端代码：

This is the server-side code the test runs:

public class Chub : Hub {
    public void CallMeBack() {
        Caller.callme();
    }
}

整天吹嘘这一天，希望有人可以提供帮助！

Blew the whole day on this, hope someone can help!

推荐答案

压缩不适合SignalR使用的EventSource，ForeverFrame等流式响应，因此，关闭压缩是目前唯一的解决方案。

Compression doesn't play well with streaming responses like EventSource, ForeverFrame, etc. as used by SignalR, so switching off compression is the only solution right now.

也许只能为〜/ signalr路径关闭压缩，我稍后会尝试并更新这个答案与结果一致。

Maybe it's possible to switch off compression just for the ~/signalr path, I'll try that later on and update this answer with the results.

更新：经过全面分析后，我发现只有在应用程序池设置为经典时才会出现此问题在IIS和动态压缩中启用模式。请参阅我对此 SignalR问题的评论。如果您使用集成模式应用程序池，则不会受到影响且SignalR按预期工作（即使启用了压缩）。

UPDATE: After a thorough analysis, I've found out this issue only occurs when the application pool is set to "Classic Mode" in IIS and Dynamic Compression is enabled. See my comment on this SignalR issue. If you use an "Integrated Mode" application pool, you are not affected and SignalR works as expected (even if compression is enabled).

如果您遇到困难经典模式+动态压缩，将以下内容添加到您的web.config中，仅为/ signalr路径关闭压缩：

In case you're stuck with Classic Mode + Dynamic Compression, add the following to your web.config for switching off compression only for the /signalr path:

<location path="signalr">
  <system.webServer>
    <urlCompression doDynamicCompression="false"/>
  </system.webServer>
</location>

这篇关于SignalR连接挂起，30秒后调用客户端的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！