问题标签 [signalr-backplane]

在 C# 项目中，我需要为使用 Azure 服务总线实现的 SignalR 制作背板。所以在启动时我写道：

在同一个项目中，甚至还有 Azure Service Bus 的 Rebus 配置，例如：

两者都使用扩展方法来实现UseAzureServiceBusand UseServiceBus。

问题是：这两个扩展方法都是两个库的一部分，并且这个库在各种依赖项上发生冲突。要拥有 Rebus 的UseAzureServiceBus扩展，我需要Rebus.AzureServiceBus版本 0.99.39，而这又需要至少WindowsAzure.ServiceBus3.0.4，但这使用了一个名为Microsoft.ServiceBus3.0.0 的 DLL，它与扩展方法 UseServiceBus 的内部工作相冲突。

我该如何处理？

编辑 1： 看起来这个问题将在Microsoft.AspNet.SignalR.ServiceBus 2.2.2 版本中得到修复。我不知道在这期间做什么

我们有几个客户端通过信号器连接到服务器。最近我们发现了一个奇怪的行为，在我们从 IIS 完成停止和启动站点后，它无法将消息从服​​务器传递到客户端。（不停止 IIS 本身，只停止站点）。当从 IIS 停止和启动时，不会触发与客户端的断开连接，并且内置的 keepalive 消息中的信号器会继续运行。此外，我们自己实现了一个类似的 keepalive 方法，它返回一个布尔值，即使在 IIS 停止/启动后也可以工作。

在上面的跟踪中，IIS 停止发生在 08:54:50 左右，启动发生在 08:55:30 左右。您可以看到没有断开连接，并且我们实现的 keepalive 和方法都可以正常通信。

问题是在包含实体（由我们定义）的 IIS 停止/启动消息无法传递之后。它尝试使用与我们发送 IsConnectionAlive 回调相同的连接 ID。但它永远不会到达客户端。这两者之间的区别是 IsConnectionAlive 仅返回一个布尔值作为参数，而其他发送实体作为参数。

以上是发送实体的服务器的日志行。

奇怪的是，我们发现通过启用背板（sql 背板），即使在 IIS 停止/启动之后，它也可以与实体一起发送消息。尽管有背板，但没有其他服务器连接到背板。此行为的原因可能是什么，以及在 IIS 停止/启动实体后未传递消息的情况。

我在我们的应用程序中集成了 SignalR，它工作得很好。几天前，由于一些要求，我们不得不支持我们的应用程序的横向扩展——因此我们选择了使用 Redis 的 SignalR 横向扩展。

但是，自从集成后，SignalR 本身就停止了工作，我们得到的错误是：NO TRANSPORT 可以成功初始化。尝试为自动初始化指定不同的传输或根本不指定。

应用的方法： - 尝试使用不同版本的 SignalR，如在线建议 - 没有帮助 - 增加连接超时 - 没有帮助

需要一些帮助来解决这个问题。也欢迎提出使用任何其他方法的建议。

[Update1] 添加代码片段

如需更多参考，我点击了此链接：https ://docs.microsoft.com/en-us/aspnet/signalr/overview/performance/scaleout-with-redis

[更新2]

我们最近使用 sql server 实现了背板。我们创建背板的服务器也包含其他数据库。这些其他数据库由不同服务器上的不同应用程序访问。对于压力测试，我们实现了一个简单的信号器客户端程序，它每 30 秒向服务器发送一条消息。有两台服务器由负载均衡器处理。当客户端数量较少时，背板可以完美运行。

问题是当客户数量更多时。（接近 50 或更多）。尝试将数据库服务器用于不同数据库的其他应用程序会引发以下异常。

由于此异常，所有其他应用程序都因无法访问数据库而中断。如果我们禁用背板，问题会立即解决。（停止两个信号服务器）。这是使用具有大量用户的背板时的预期行为还是背板的问题？

PS - 我们注意到抛出这些异常的机器有超过 3000 个线程分配给 w3wp.exe 进程。似乎他们被困在手术中。

We have a simple signalr server and client running with the backplane enabled. When I looked in to the IIS worker process I found out in the current requests tab there is always this signalr connect is showing.

When I connect like 100 clients 100 current requests are shown in the woker process view. Shouldn't these be removed after connecting or is this the expected behavior from the signalr?

我们有一个服务器和客户端，它们被实现为通过信号器进行通信。我们已经使用 SQL Server 实现了横向扩展，后来又使用了 Redis。当将大约 70 个客户端连接到服务器时，所有客户端都突然断开连接。以下是来自客户端的跟踪日志。

更糟糕的是，当我们查看服务器机器资源监视器时，我们可以看到 w3wp.exe 分配了超过 1000 个线程，并且还在不断增加。

当我们调查 IIS 中的工作进程时，会显示大量的工作进程当前请求。

有一次，IIS 线程增加到 10,000 个线程并挂起服务器计算机。这个问题的原因是什么？

IIS 8.0 服务器 - Windows 2012

我正在将 MongoDB SignalR（版本 2.2.1）背板添加到现有 SignalR 集线器。如果没有背板，则调用集线器上的 OnConnected 方法，一旦注册了背板，就不会调用 OnConnected 方法。使用调试器，我可以看到当客户端订阅时，我的背板 ScaleoutMessageBus 的订阅和发送方法被调用，但 OnConnected 方法从未被调用。

我的 OnConnected 方法：

我的 ScaleoutMessageBus：

我只在一台服务器上进行测试，所以我希望我应该看到在该服务器上调用的 OnConnected 事件。我需要处理一些事情来确保使用背板调用 OnConnected 吗？

我们已经实现了一个带有背板的服务器，其中有 100 多个客户端正在连接。但是当我们对其进行测试时，我们发现当客户端断开连接时，它们都无法重新连接。我们还注意到 w3wp.exe 使用大量线程（超过 5000 个），然后 IIS 崩溃。

为了确定这是什么原因，我们清理了集线器，我们发现当记录器类被删除时，背板工作正常。我们使用了 NLog 记录器并将其作为静态记录器启动。

为了确认 NLog 是否有问题，我们在集线器类中创建了另一个静态对象，但它也显示出相同的高线程使用率。因此，似乎只要有静态对象，客户端就无法重新连接，并且 w3wp.exe 服务中的线程使用率很高。造成这种情况的原因是什么？

PS-我们使用 SQL 和 redis 背板进行了测试，结果完全相同。

我们已经创建了一个带有 SQL 背板的服务器。最近，我们发现这个问题导致 w3wp.exe 使用大量线程。在浏览了整个代码库之后，我们能够缩小原因与 NLog 相关。

我们通过 web config 文件中的配置来配置 NLog。

在集线器内部，我们使用了如下所示的记录器。

当我们在启用这些配置的情况下运行背板时，当客户端尝试重新连接时，我们面临着大量线程使用的问题。但是如果我们从 web 配置文件中注释掉 NLog 配置代码，那么背板就可以正常工作了。有没有人在使用背板时遇到过类似的行为？这种行为的原因可能是什么？

SignalR 版本 - 2.2.2 NLog 版本 - 4.4.9

编辑 1

当我们从 webconfig 禁用信号器跟踪日志记录时，问题似乎没有发生。我们习惯于NLog.NLogTraceListener记录信号器跟踪。

而不是 usingNLog.NLogTraceListener和 using System.Diagnostics.TextWriterTraceListenerinstead 似乎也没有给出任何问题。

我Redis用作背板，但我也使用 SQL 将用户映射到连接。这对我的 I/O 造成了影响——每次我通过集线器发送消息时，我都会这样做：

这是哪里GetConnections：

我还做了一大堆 I/O 来定期删除不活动的连接。

SignalR 能否以某种方式推断用户名（例如 from User.Identity.Name）并自动处理映射和连接过期，以便我可以从 SignalR 实现中清除此 SQL 依赖项？