未在rebus中处理的随机消息

我对rebus的实现有一个奇怪的问题,在过去的几年里,它一直在工作,没有任何问题,我正在试图找出问题的范围,以及在哪里集中我的故障排除工作。一点背景:

• 我们运行的是0.99.66版本
• 上周移到3.1.5版,然后看到问题出现
• 回滚到0.99.66,问题继续
• 使用msmq进行传输
• 运行Windows Server 2016
• 在其他服务器实例上运行的相同代码没有问题

因此,我们遇到了一些看似随机的实例,其中消息出现故障,最后出现在错误队列中,并返回一个rebs错误,该错误表示消息无法发送到任何处理程序。这可能会发生一次,但当下次出现相同的消息类型时,它会得到正确的处理。

下面是一段有问题的代码:

public class ProcessManagerService
{
    public ProcessManagerService()
    {
        ...

        BusAdapter = new BuiltinHandlerActivator();
        BusAdapter.Handle<FileEventMessage>(async msg => await StartProcess(msg));
        BusAdapter.Handle<ProcessRequest>(async msg => await StartProcess(msg));

        Bus = Configure.With(BusAdapter)
                .Logging(l => l.ColoredConsole(LogLevel.Error))
                .Transport(t => t.UseMsmq(ConfigurationManager.AppSettings["Queue"]))                   
                .Start();            
    }

    ...

    public async Task StartProcess(FileEventMessage msg)
    {
        var svc = new StepManager() { FileEvent = msg.FileEvent };
        await svc.Run();
    }

    public async Task StartProcess(ProcessRequest msg)
    {
        var svc = new StepManager();
        await svc.Run(msg);
    }
}

下面是抛出异常的一个例子:

5个未处理的异常:2018年12月18日上午7:53:00-06:00: rebs.exceptions.rebusApplicationException:ID为的消息 C72A8B6D-E31C-4A88-937E-612BF1DB8B11和类型 clearstone.messages.monitoring.file.fileeventmessage, 无法将clearstone.messages调度到处的任何处理程序 rebus.pipeline.receive.DispatchIngMessageStep.d_uuu 1.moveNext()。 ---从先前引发异常的位置开始的堆栈跟踪结束---at system.runtime.compilerServices.taskWaitier.throwForOnSuccess(任务 任务) system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务 任务)在rebus.sagas.loadsagadatastep.d_uu7.moveNext()时 ---从先前引发异常的位置开始的堆栈跟踪结束---at system.runtime.compilerServices.taskWaitier.throwForOnSuccess(任务 任务) system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务 任务) rebs.pipeline.receive.activateHandlersStep.d_uuu 3.moveNext()。 ---从先前引发异常的位置开始的堆栈跟踪结束---at system.runtime.compilerServices.taskWaitier.throwForOnSuccess(任务 任务) system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务 任务) rebs.pipeline.receive.deserializinecomingmessagestep.d_uuu 2.moveNext()) ---从先前引发异常的位置开始的堆栈跟踪结束---at system.runtime.compilerServices.taskWaitier.throwForOnSuccess(任务 任务) system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务 任务) rebus.pipeline.receive.handleDeferredMessagesStep.d_uuu 12.moveNext()) ---从先前引发异常的位置开始的堆栈跟踪结束---at system.runtime.compilerServices.taskWaitier.throwForOnSuccess(任务 任务) system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务 任务) rebs.retry.simple.simpleretrystrategystep.d_uuu 8.moveNext()。

更新:这里有一个更详细的在rebs源中连接后的堆栈跟踪:

5个未处理的异常:2018年12月20日上午9:39:05-06:00:rebs.exceptions.rebusApplicationException:ID为84c3605a-41de-4300-9596-97e7288d2bcb的消息,并键入clearstone.messages.monitoring.file.fileeventmessage,clearstone。消息无法发送到任何处理程序 在rebus.pipeline.receive.DispatchIngMessageStep.d_uuu 1.moveNext()中,C:\temp\rebus_0_99_archive\rebus\pipeline\receive\DispatchIngMessageStep.cs:line 61 ---从先前引发异常的位置开始的堆栈跟踪结束--- 在System.Runtime.CompilerServices.TaskWaiter.ThrowForOnSuccess(任务任务) 在system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务任务) 在System.Runtime.CompilerServices.TaskWaiter.GetResult()时 在c:\temp\rebs_0_99_66_archive\rebs\sagas\loadsagadatastep.d_uu7.movenext()中的rebs.sagas.loadsagadatastep.cs:line 77 ---从先前引发异常的位置开始的堆栈跟踪结束--- 在System.Runtime.CompilerServices.TaskWaiter.ThrowForOnSuccess(任务任务) 在system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务任务) 在System.Runtime.CompilerServices.TaskWaiter.GetResult()时 在rebus.pipeline.receive.activatehandlersstep.d_uuu 3.movenext()中,C:\temp\rebus_0_99_存档\rebus\pipeline\receive\activatehandlersstep.cs:line 48 ---从先前引发异常的位置开始的堆栈跟踪结束--- 在System.Runtime.CompilerServices.TaskWaiter.ThrowForOnSuccess(任务任务) 在system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务任务) 在System.Runtime.CompilerServices.TaskWaiter.GetResult()时 在rebus.pipeline.receive.deserializinecomingmessagestep.d_uu2.movenext()中,C:\temp\rebus_0_99_archive\rebus\pipeline\receive\deserializinecomingmessagestep.cs:line 36 ---从先前引发异常的位置开始的堆栈跟踪结束--- 在System.Runtime.CompilerServices.TaskWaiter.ThrowForOnSuccess(任务任务) 在system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务任务) 在System.Runtime.CompilerServices.TaskWaiter.GetResult()时 在rebus.pipeline.receive.handleDeferredMessagesStep.d_uu12.moveNext()中,C:\temp\rebus_0_99_66存档\rebus\pipeline\receive\handleDeferredMessagesStep.cs:line 114 ---从先前引发异常的位置开始的堆栈跟踪结束--- 在System.Runtime.CompilerServices.TaskWaiter.ThrowForOnSuccess(任务任务) 在system.runtime.compilerservices.taskwaiter.handlenonsuccessanddebuggernotification(任务任务) 在System.Runtime.CompilerServices.TaskWaiter.GetResult()时 位于c:\temp\rebus_0_99_66_archive\rebus\retry\simple\simpleretrystrategystep.d_uu8.movenext()中的at rebus.retry.simple.simpleretrystrategystep.cs:line 105

假设在这个特定的服务器实例/环境中存在明显的问题,那么我将尝试弄清楚rebus为什么会这样做,以及在我的环境中是什么导致了这种情况。无论从何处开始寻找,我们都将不胜感激!