我正在尝试调试进入MSMQ队列正在建立但不再处理消息的状态的应用程序。
我对Rebus / MSMQ的理解是非常基础的(我已经与原始开发人员很好地继承了该应用程序,并且确实消失了。)
我想了解为什么Rebus在重新启动应用程序时不读取队列中当前存在的消息?我的理解是,在将消息放入队列时,Rebus是由事件驱动的,如果应用程序处于错误状态,则这些消息将被放入队列,并且永远不会被处理。
我一直在阅读Rebus的文档,似乎找不到比管道解释更多的信息。
此应用程序中的代码太多,无法真正在此处发布,但是该应用程序使用Rebus.Ninject版本0.80.1(这是一个旧应用程序)。
我将编辑以包括人们需要的任何信息。
编辑:
var bus = Configure.With(new NinjectContainerAdapter(context.Kernel))
.Logging(l => l.NLog())
.Transport(t => t.UseMsmq(sourceQueue, errorQueue))
.MessageOwnership(d => d.Use(new CustomBusMessageOwnership(uowFactory)))
.Serialization(s => s.UseCustomJsonSerialization())
.CreateBus()
.Start(numWorkers);
UseCustomJsonSerialization方法仅将编码设置为UTF8,将SerializeEnumAsStrings设置为true。
编辑2: 终于有机会再次对此进行研究。我为其中一个安装创建了一个自动崩溃转储,该安装似乎比其他安装失败的频率更高。
这是WinDbg的堆栈跟踪:
00000000 00000001 mscorlib_ni!System.RuntimeMethodHandle.InvokeMethod+0x2
0763ee84 6ef6f561 mscorlib_ni!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal+0xa1
0763eea8 6ef6f096 mscorlib_ni!System.Reflection.RuntimeMethodInfo.Invoke+0x66
0763eedc 6ef640b6 mscorlib_ni!System.Reflection.MethodBase.Invoke+0x16
0763eee8 07355234 UNKNOWN!Rebus.Bus.Worker+_DoTry_d__2b.MoveNext+0x57c
0763efa4 07354c73 mscorlib_ni!System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[[Rebus.Bus.Worker+_DoTry_d__2b,_Rebus]]+0x43
0763eff8 07354c0a UNKNOWN!Rebus.Bus.Worker.DoTry+0x6a
0763f074 073546f2 UNKNOWN!Rebus.Bus.Worker+_TryProcessIncomingMessage_d__23.MoveNext+0x62
0763f0ac 0735424b mscorlib_ni!System.Runtime.CompilerServices.AsyncVoidMethodBuilder.Start[[Rebus.Bus.Worker+_TryProcessIncomingMessage_d__23,_Rebus]]+0x43
0763f100 073541f0 UNKNOWN!Rebus.Bus.Worker.TryProcessIncomingMessage+0x40
0763f144 07353ffe UNKNOWN!Rebus.Bus.Worker.MainLoop+0x5e
0763f174 6ef66d11 mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context+0x9d
0763f180 6ef866ea mscorlib_ni!System.Threading.ExecutionContext.RunInternal+0xea
0763f1f0 6ef865f6 mscorlib_ni!System.Threading.ExecutionContext.Run+0x16
0763f204 6ef865b1 mscorlib_ni!System.Threading.ExecutionContext.Run+0x41
0763f21c 6ef66c6c mscorlib_ni!System.Threading.ThreadHelper.ThreadStart+0x44