Сопоставление сбойных сообщений с их исключениями в NServiceBus с использованием MSMQ

#c# #.net #error-handling #msmq #nservicebus

#c# #.net #обработка ошибок #msmq #nservicebus

Вопрос:

При настройке NServiceBus с MSMQ с использованием стандартных параметров конфигурации iServer вы определяете:

  • входная очередь
  • очередь ошибок.

Когда вашему обработчику сообщений NServiceBus по какой-либо причине не удается обработать сообщение, он выдает исключение и перемещает сообщение в очередь ошибок.

Является ли сообщение в очереди ошибок точно таким же сообщением, которое было в очереди ввода? Если это так, что я предполагаю, есть ли какой-либо способ узнать, почему эти сообщения завершились ошибкой? К ним прикреплены какие-либо метаданные, которые могут содержать исходное исключение, которое было вызвано?

Возможность сделать это было бы особенно полезно в сценариях, когда ваш обработчик настроен на повторную попытку в несколько раз больше единицы. Это потому, что даже если в обработчике могут возникать фатальные ошибки и они регистрируются, они на самом деле не являются фатальными как таковые, пока не попадут в очередь ошибок, потому что именно тогда они на самом деле завершаются сбоем.

Есть идеи?

приветствия

Ответ №1:

Это точная копия сообщения, которое отправляется при ошибке q. Идентификатор сообщения и исходная очередь сохраняются в заголовках, чтобы разрешить воспроизведение сообщения. В версии 2.5 нет хорошего способа получить сведения об исключении для сбойного сообщения, поэтому вам приходится сопоставлять идентификатор сообщения с записями в файлах журнала. Тот факт, что NSB повторяет за вами, часто приводит к тому, что одно и то же logmessage отображается несколько раз для сообщения, поэтому обязательно используйте последнюю запись.

Это, конечно, не очень удобно для пользователя и было исправлено в предстоящей версии 3.0, где вы можете зарегистрировать диспетчеры сбоев, которые позволяют подключаться к NSB для получения этой информации. Диспетчер сбоев по умолчанию помещает сведения об исключении в заголовки, чтобы вы могли легко получить к ним доступ, просмотрев сообщение о сбое.

Комментарии:

1. 1 хм … это то, что я подумал. 3.0 звучит неплохо, хотя это позор для 2.5, особенно, как вы говорите, из-за повторных попыток. Спасибо.