使用 Azure 服务总线背板时出现奇怪的间歇性 SignalR 故障
Strange intermittent SignalR failures when using Azure Servicebus Backplane
我们在使用 SignalR 2.2.0 和 Microsoft ASP.NET SignalR Service Bus Messaging Backplane 某些 Azure 服务总线实例[=28] 时，在我们的开发和生产环境中看到奇怪的行为=].一些服务总线似乎损坏并堵塞，我们看到如下所述的问题。
首先，这是我的 OWIN 启动代码：
public void Configuration(IAppBuilder app)
{
string connectionString = System.Configuration.ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"];
GlobalHost.DependencyResolver.UseServiceBus(connectionString, "MyApplicationName");
// Branch the pipeline here for requests that start with "/signalr"
app.Map("/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
var hubConfiguration = new HubConfiguration
{
//EnableJSONP = true,
EnableDetailedErrors = true
};
map.RunSignalR(hubConfiguration);
});
}
我们问题的症状是 SignalR 间歇性地无法使用任何传输进行连接。与 运行 无背板相比，性能较慢，并且在 SignalR 客户端上启用了详细日志记录，我看到消息 "SignalR: webSockets transport timed out when trying to connect." SignalR 然后尝试通过其余传输（永远帧，长轮询）然后放弃。
最重要的是：对于我们的一些服务总线实例，性能非常稳定，我们从来没有遇到过问题。其他服务总线实例会导致上述问题。
为什么我们有多个服务总线？我们只为我们的应用程序使用一个，但每个开发人员都有一个服务总线实例可以使用。 Azure 服务总线已损坏，这让我夜不能寐，我不知道为什么。
问题：
- 还有其他人遇到过这个问题吗？
- 您是否见过服务总线实例在 SignalR 或其他应用程序中损坏或行为不当？
- 什么可以解释这种行为？
这是一个旧的 post，但我们遇到了一个非常相似的问题，让我们抓狂。当我们将 SignalR 与服务总线背板一起使用时，就会发生这种情况。
在我们的异常日志中，我们发现了以下内容：
The X.509 certificate CN=servicebus.windows.net is not in the trusted
people store. The X.509 certificate CN=servicebus.windows.net chain
building failed. The certificate that was used has a trust chain that
cannot be verified. Replace the certificate or change the
certificateValidationMode. A certificate chain could not be built to a
trusted root authority.
解决方法是在我们的应用程序启动中添加以下代码行。对我们来说，那是 global.asax.cs:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
之后，我们的服务总线背板和SignalR运行完美结合。
要更深入地讨论正在发生的事情，check out this SO post。
我们在使用 SignalR 2.2.0 和 Microsoft ASP.NET SignalR Service Bus Messaging Backplane 某些 Azure 服务总线实例[=28] 时，在我们的开发和生产环境中看到奇怪的行为=].一些服务总线似乎损坏并堵塞，我们看到如下所述的问题。
首先，这是我的 OWIN 启动代码：
public void Configuration(IAppBuilder app)
{
string connectionString = System.Configuration.ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"];
GlobalHost.DependencyResolver.UseServiceBus(connectionString, "MyApplicationName");
// Branch the pipeline here for requests that start with "/signalr"
app.Map("/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
var hubConfiguration = new HubConfiguration
{
//EnableJSONP = true,
EnableDetailedErrors = true
};
map.RunSignalR(hubConfiguration);
});
}
我们问题的症状是 SignalR 间歇性地无法使用任何传输进行连接。与 运行 无背板相比，性能较慢，并且在 SignalR 客户端上启用了详细日志记录，我看到消息 "SignalR: webSockets transport timed out when trying to connect." SignalR 然后尝试通过其余传输（永远帧，长轮询）然后放弃。
最重要的是：对于我们的一些服务总线实例，性能非常稳定，我们从来没有遇到过问题。其他服务总线实例会导致上述问题。
为什么我们有多个服务总线？我们只为我们的应用程序使用一个，但每个开发人员都有一个服务总线实例可以使用。 Azure 服务总线已损坏，这让我夜不能寐，我不知道为什么。
问题：
- 还有其他人遇到过这个问题吗？
- 您是否见过服务总线实例在 SignalR 或其他应用程序中损坏或行为不当？
- 什么可以解释这种行为？
这是一个旧的 post，但我们遇到了一个非常相似的问题，让我们抓狂。当我们将 SignalR 与服务总线背板一起使用时，就会发生这种情况。
在我们的异常日志中，我们发现了以下内容：
The X.509 certificate CN=servicebus.windows.net is not in the trusted people store. The X.509 certificate CN=servicebus.windows.net chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain could not be built to a trusted root authority.
解决方法是在我们的应用程序启动中添加以下代码行。对我们来说，那是 global.asax.cs:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
之后，我们的服务总线背板和SignalR运行完美结合。
要更深入地讨论正在发生的事情，check out this SO post。