Сообщения в очереди MSMQ не читаются Rebus - PullRequest
Новая
       25

Сообщения в очереди MSMQ не читаются Rebus

1 голос
/ 29 марта 2019

Я пытаюсь отладить приложение, когда оно попадает в состояние, когда очередь MSMQ накапливается, но сообщения больше не обрабатываются.

Мое понимание Rebus / MSMQ очень простое (Я унаследовал это приложение с оригинальными разработчиками и действительно ушел).

Я хочу понять, почему Ребус, когда я перезапускаю приложение, не читает сообщения в очереди, которая существует в настоящее время?Насколько я понимаю, Rebus управляется событием в тот момент, когда сообщение помещается в очередь, и если приложение находится в состоянии ошибки, то эти сообщения будут помещаться в очередь и никогда не обрабатываться.

I 'Я читал документацию для 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
...