我正在使用带有集线器的SignalR 0.5.3,我明确地将传输设置为长轮询,如下所示:
$.connection.hub.start({ transport: 'longPolling' }, function () {
console.log('connected');
});
使用这样的配置(在global.asax.cs Application_Start方法中):
GlobalHost.DependencyResolver.UseRedis(server, port, password, pubsubDB, "FooBar");
GlobalHost.Configuration.DisconnectTimeout = TimeSpan.FromSeconds(2);
GlobalHost.Configuration.KeepAlive = TimeSpan.FromSeconds(15);
然而,长期轮询似乎既不适用于开发(IIS express)也不适用于生产(IIS 7.5)环境。连接似乎正常,但长轮询请求总是超时(约2分钟后),之后重新连接。 IIS的日志是here。第一次超时请求的回复:
{"MessageId":"3636","Messages":[],"Disconnect":false,"TimedOut":true,"TransportData":{"Groups":["NotificationHub.56DDB6692001Ex"],"LongPollDelay":0}}
超时重新连接响应如下所示:
{"MessageId":"3641","Messages":[],"Disconnect":false,"TimedOut":true,"TransportData":{"Groups":["NotificationHub.56DDB6692001Ex"],"LongPollDelay":0}}
对于这个问题,我将不胜感激。感谢。
修改
如果重新连接意味着新的长轮询周期的开始,为什么在global.asax.cs中的KeepAlive设置设置为15秒后~2分钟后启动?问题在于我在IIS前面有一个反向代理,在25秒后超时保持活动请求,因此当达到此反向代理超时时,我得到504响应。
答案 0 :(得分:5)
看一下这篇文章:How signalr works internally。长时间拉动的方式是在设定的时间之后连接将超时或接收响应和重新连接(重新连接)
答案 1 :(得分:0)
长轮询禁用保持活动功能。似乎使用了 ConnectionTimeout。
<块引用>此设置代表离开交通工具的时间量 连接打开并在关闭之前等待响应 打开一个新的连接。默认值为 110 秒。
如果请求超时并且服务器没有发送任何数据,但您希望它发送,则可能是服务器端的一些您还没有看到的问题。