问题标签 [nservicebus3]

我们注意到具有长时间运行请求的消息处理程序的问题，如果在分布式事务超时之前请求未完成处理，则在原始消息完成处理之前或什至在原始消息之前在新线程上重新处理相同的消息引发错误。消息最终会到达错误队列。

以下是我们重现该问题的方式：

将本地机器配置更新为事务的默认超时 1 分钟：

将 NSB 消息服务配置为多线程：

然后在我们的处理程序中，线程休眠了 2 分钟（下面的代码），发生的情况是在工作线程 A 上出现一条消息。一旦发生 1 分钟超时，工作线程 B 上会处理相同的消息，工作线程 A 仍然睡眠。工作线程 A 最终返回并出现“无法在事务中登记”错误。然后再次重新开始处理消息，这将在两个工作线程上继续，直到消息最终进入错误队列。

这是一个已知问题，还是我们应该设计我们的代码以避免发生这种类型的密集重新处理？

从nservicebus版本3升级到版本4，收到如下错误信息

“没有配置消息序列化程序。”

堆栈跟踪：

在 c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Unicast\UnicastBus.cs:NServiceBus.Unicast.UnicastBus.ValidateConfiguration() 中的 NServiceBus.Unicast.UnicastBus.ValidateConfiguration() 中的第 866 行 NServiceBus.Unicast.UnicastBus.Start(Action startupAction) 在 c :\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Unicast\UnicastBus.cs：C:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus 中 NServiceBus.Unicast.UnicastBus.Start() 的第 739 行。 Core\Unicast\UnicastBus.cs: d:\dev\backup\soa_cyclemonkey\Inventory\Inventory.CreateOrder\IT_OPS\CustomInit.cs 中 CycleMonkey.Inventory.CreateOrder.IT_OPS.CustomInit.Init() 的第 718 行：NServiceBus 中的第 20 行.Hosting.Configuration.ConfigManager.ConfigureCustomInitAndStartup() 在 c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Hosting\Configuration\ConfigurationManager.cs:NServiceBus 的第 43 行。c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\NServiceBus.Core\Hosting\GenericHost.cs 中的 Hosting.GenericHost.PerformConfiguration()：c:\TeamCity\buildAgent 中 NServiceBus.Hosting.GenericHost.Start() 的第 126 行\work\d4de8921a0aabf04\src\NServiceBus.Core\Hosting\GenericHost.cs：C:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\hosting\NServiceBus.Hosting 中 NServiceBus.Hosting.Windows.WindowsHost.Start() 的第 29 行.Windows\WindowsHost.cs：NServiceBus.Hosting.Windows.Program.<>c_ 的第 56 行\TeamCity\buildAgent\work\d4de8921a0aabf04\src\hosting\NServiceBus.Hosting.Windows\WindowsHost.cs：NServiceBus.Hosting.Windows.Program 的第 56 行。<>c_\TeamCity\buildAgent\work\d4de8921a0aabf04\src\hosting\NServiceBus.Hosting.Windows\WindowsHost.cs：NServiceBus.Hosting.Windows.Program 的第 56 行。<>c_DisplayClassd.b _5（WindowsHost 服务）在 c:\TeamCity\buildAgent\work\d4de8921a0aabf04\src\hosting\NServiceBus.Hosting.Windows\Program.cs：Topshelf.Internal.ControllerDelegates 1 的第 76 行1.StartActionObject(Object obj) in c:\Projects\TopShelfForNSB\src\Topshelf\Internal\ControllerDelegates.cs:line 18 at Topshelf.Internal.IsolatedServiceControllerWrapper。<>c_ DisplayClass2.b _1（TService 服务）在 c:\Projects\TopShelfForNSB\src\Topshelf\Internal\IsolatedServiceControllerWrapper.cs:line 65 at Topshelf.Internal.ServiceController 1.<.cctor>b__1(ServiceController1 sc) 在 c:\Projects\TopShelfForNSB\src\Topshelf\Internal\ServiceController。 cs:第 35 行 Magnum.StateMachine.LambdaAction 1.Execute(T instance, Event event, Object parameter) in :line 0 at Magnum.StateMachine.EventActionList1.Execute(T stateMachine, Event event, Object parameter) in :line 0

升级中是否遗漏了什么？正在运行的代码版本 3：

相同代码的第 4 版以及升级所需的建议更改

我们有一个当前向 NServiceBus (v3) 服务发送命令的 ASP.NET MVC 应用程序。

该服务发布我们需要在 Web 应用程序中订阅的事件，以便我们可以向用户显示实时通知。

总线当前在 Web 应用程序中初始化如下：

在 web.config 中使用以下配置：

但是，我在 Web 应用程序中创建的事件处理程序没有被调用，没有为 Web 应用程序创建队列，也没有看到任何发送到主机的订阅消息。

我错过了什么吗？

本周我们的 NServiceBus 系统落后了（300,000 条消息）。

我们目前每秒处理大约 4 条消息，所以赶上时间太长了。

为了加快速度，我们为每条 NServiceBus 消息添加了更多对象（每条消息 20 个）。

通常，如果需要一起处理，我们只会在消息中放入多个对象。

但是这种变化给我们带来了显着的性能改进（我们现在每秒处理大约 8 条消息）。我们将此归因于 NServiceBus 工作者和分发者之间的较少握手。

但现在我们发现这个伟大的解决方案存在问题。当消息失败时，所有 20 个对象都会进入错误队列。当真的只有一两个人有问题时。

我们需要一种方法来分解这些消息并再次尝试它们。ReturnToSourceQueue.exe 上是否有可以做到这一点的选项？

我对 NServiceBusHost.exe 有疑问。

目前，我正在将 NServiceBusHost.exe 作为 Windows 服务运行，并且收到超时异常，如下所示：

Microsoft 服务跟踪查看器输出：

我正在考虑避免发生此超时异常，应该为 HTTP 运行时延长超时。

有谁知道我认为 .NET 中的 HTTPRuntime 配置执行超时（.NET 4.0 中的默认值为 1:10 分钟）适用于 NServiceBusHost.exe 是否正确？

此外，我相信 NServiceBusHost.exe 是建立在 topshelf 之上的。我认为可以应用 log4net 配置来记录 NServiceBusHost.exe 的任何问题是否正确？

提前致谢。

我正在考虑将我们的 NServiceBus 3.3.3 系统升级到版本 4。

我阅读了一些似乎表明版本 4 可以在没有 DTC 的情况下工作的帖子。这是真的？

基本上，这就是我正在考虑做的事情：

1. 更改我的处理程序以能够处理重复的消息
2. 升级到 NServiceBus 版本 4
3. 在我的数据库上关闭 DTC

根据我的阅读，我应该能够做到这一点并且不会丢失任何消息。（我在一家医疗公司工作，丢失消息意味着我们丢失了患者的数据（非常非常糟糕）。）

唯一需要注意的另一件事是，我的系统与分销商一起运行，然后将工作分配给几个工人。通过 put 的消息很大，（我希望删除 DTC 会提高吞吐量）。

作为旁注，如果我从 MSMQ 切换到 RabbitMQ，这会有什么不同吗？

我正在对提高性能进行优化，我发现某些消息的大小不一定很大但结构复杂，在发送后需要更多时间才能在处理程序处接收，在同一物理机器上运行的端点之间大约需要 3 秒。这我怀疑 Serializer 需要更多时间来处理序列化和反序列化。我正在使用BinarySerializer，有什么方法可以计算序列化程序所花费的时间。有没有办法通过单元测试（NServiceBus.Test）调用序列化程序

I've tried everything I can think of but I can't get NServiceBus performance counters to work.

NServiceBus version: 3.2.8

I've installed the Performance Counters using the NServiceBus.Unicast.Monitoring.PerformanceCounterInstaller from the 3.2.8 NServiceBus.Core assembly and they are visible in Performance Monitor, but I can't get any instances to appear.

I've tried running NServiceBus.Host.exe from an elevated command prompt using the NServiceBus.Production & NServiceBus.PerformanceCounters profiles. I added my user account to the Performance Monitor Users security group, although I'm already a local admin. I passed some messages through the service.

But I just can't get any performance counter instances...

Does anyone have a suggestion?

我们在 NServiceBus 代码堆栈跟踪的日志中看到非常奇怪的间歇性错误

我们使用的 NServiceBus 版本是 3.3.4

这里是错误的堆栈跟踪：

任何想法是什么问题？我们的生产代码有时会因此而失败，我们需要知道原因。

谢谢。任何帮助，将不胜感激。

我们在生产中使用 NServiceBus，在我们的日志文件中我们看到以下错误：

目标机器上的队列存在（双重检查）。这里奇怪的是，它不会一直发生并且对于发送到该队列的每条消息，而是偶尔发生（这意味着有消息到达该队列）。

搜索了一下，没有找到类似的案例。

我在这里想念什么？