Что-то, из-за чего NServiceBus теряет сообщения

У меня есть конфигурация NServiceBus, которая отлично работает на машинах разработчиков и в моей среде разработки.

Однако, когда я перемещаю его в свою тестовую среду, мои сообщения просто начинают отбрасываться.

Вот система:

  1. Приложение получает TCP-сообщение от системы мэйнфреймов и отправляет его в MSMQ (назовем его FromMainframe).
  2. Приложение, размещенное в IIS, имеет метод «Handle» для этого MSMQ и обрабатывает сообщения от мейнфрейма.

В моей тестовой среде второй шаг выполняется только наполовину. Сообщение выскакивает из MSMQ, но не обрабатывается моим приложением.

Фактически мои данные ПОТЕРЯНЫ! NServiceBus удаляет их из очереди, но я никогда не могу их обработать. Их нет даже в очереди ошибок!

Вот что я пробовал, пытаясь понять, что происходит:

  1. Проверьте файлы конфигурации
  2. Attach a remote debugger to the process to see what the Handle method is doing
    • The Handle method is never called (but when I attach to the Development Environment my breakpoint in my Handle method is hit and it all works flawlessly).
  3. Повторно разверните мою версию Dev в тестовой среде и повторите шаг 2 (на всякий случай, если версии не совпадают).
  4. Проверьте файлы конфигурации еще раз
  5. Check that the Error queue is not filling up
    • The error queue stays empty (I wish it would fill up, then my data would not be LOST).
  6. Check for any other process that may be pulling stuff from my MSMQs
    • I Turned off my IIS website and the messages in the FromMainframe queue start to backup.
    • Когда я снова включаю его, сообщения исчезают довольно быстро (но все же не все сразу). Скорость, с которой они исчезают, слишком высока, чтобы их можно было обработать с помощью моего метода Handle.
  7. Проверьте файлы конфигурации еще раз.
  8. Run the NServiceBusTools\MsmqUtils\Runner.exe \i
    • I ran it, rebooted, ran it again and again for good measure!
  9. Снова проверьте конфиги (должно быть, я ЧТО-ТО пропустил, верно?)
  10. Check the Development Environment Configs are not pointing to the Test Environment
    • I don't think it is possible to use another computer's MSMQ as your input queue, but it does not hurt to check.
  11. Ищите любые блоки catch, которые могут молча убить мое сообщение.
  12. Последняя проверка файлов конфигурации.
  13. Воссоздайте мою тестовую среду на другой машине (она работала безупречно)
  14. Run my stuff outside of IIS.
    • When I host outside of IIS (using NServiceBus.Host.exe) it all works fine. So it has to be an IIS thing right?
  15. Сходите с ума и надейтесь, что переполнение стека может дать хоть какую-то информацию.

iis iis-7 nservicebus
person Vaccano    schedule 19.03.2012    source источник
comment
Размещается ли NSB внутри IIS? Для каких протоколов он настроен? Является ли ваша очередь транзакционной? Работает ли MSDTC? Имеет ли идентификатор пула приложений правильные разрешения в очереди? Попадают ли сообщения в системную очередь недоставленных сообщений?   -  person Adam Fyles    schedule 20.03.2012
comment
Вы настроили log4net для захвата всего вывода nservicebus? Ваш ответ может быть там. Также какая версия nservicebus?   -  person Sarmaad    schedule 20.03.2012
comment
@AdamFyles — NSB размещается в IIS. Мне нужно будет проверить протоколы (не думал, что это повлияет на NSB). Мой MSMQ был настроен NSB. Так что я бы предположил, что это транзакционный. Пул приложений имеет правильные разрешения. Сообщения не попадают в очередь недоставленных сообщений. (Они просто ушли)   -  person Vaccano    schedule 20.03.2012
comment
@Sarmaad - я этого не делал. И я не знаю, как это сделать. Если вы знаете, как, пожалуйста, напишите это. (Если нет, я откопаю его.) У меня NSB 2.6.0.1506.   -  person Vaccano    schedule 20.03.2012
comment
Можете ли вы прочитать очередь из кода вне IIS? Вы также можете попробовать включить ведение журнала исключенных источников в MSMQ. Это поможет вам определить, что происходит с сообщениями.   -  person Adam Fyles    schedule 20.03.2012
comment
@AdamFyles - я не думаю, что ведение журнала негативных источников поможет. Я вижу, как заполняется очередь. Сообщения туда попадают нормально. Когда приложение переходит к их обработке, возникает проблема. Дескриптор никогда не вызывается. Как будто у NServiceBus есть что-то, что говорит ему считать сообщение обработанным, прежде чем он когда-либо вызовет Handle. (Возможно, я не понимаю ведение журнала негативных источников, но я думал, что это для проблем, когда сообщение никогда не приходит.)   -  person Vaccano    schedule 20.03.2012
comment
Мне было интересно, может ли это понять, почему они не попадают в очередь ошибок. Я в тупике, почему NSB не показывает никаких ошибок, поэтому я склоняюсь к тому, что что-то не так в инфраструктуре. Можете ли вы опубликовать, как настроена ваша конечная точка?   -  person Adam Fyles    schedule 21.03.2012
comment
@AdamFyles - я не знаю, как включить ведение журнала отрицательных источников прямо в очереди. Я вижу только вариант для обычного ведения журнала. Вы знаете, как включить его?   -  person Vaccano    schedule 21.03.2012
comment
@AdamFyles - я попытался настроить свой MSMQ для работы вне IIS (используя NServiceBus.Host.exe). Это сработало отлично! Я думаю, это означает, что это должно быть связано с IIS. Поэтому я добавил IIS в теги.   -  person Vaccano    schedule 21.03.2012
comment
@AdamFyles - я проверил протоколы. Это: http, net.tcp, net.pipe, net.msmq, msmq.formatname.   -  person Vaccano    schedule 21.03.2012
comment
Я бы попробовал отключить протоколы на основе msmq или отключить соответствующие службы прослушивания на случай, если WAS крадет ваши сообщения. Вот хорошая ссылка на отсутствующие сообщения: blogs.msdn.com/b/johnbreakwell/archive/2010/01/22/   -  person Adam Fyles    schedule 21.03.2012
comment
@AdamFyles - Спасибо за вашу помощь в этом. Кажется, я получил ответ о том, что произошло. (Увидеть ниже)   -  person Vaccano    schedule 21.03.2012

Ответы (1)


arrow_upward
2
arrow_downward

Так что я знаю достаточно о том, что произошло, чтобы выбросить "Ответ".

Когда я устанавливал собственный хостинг NServiceBus, у меня был вызов, который загружал обработчики сообщений.

NServiceBus.Configure.With().LoadMessageHandlers()

(Есть еще конфигурации, но я их опустил для краткости)

Когда вы вызываете это, NServiceBus сканирует сборки для класса, который реализует IHandleMessages<T>.

Итак, каким-то образом на моем компьютере с тестовой средой сканирование ServiceBus каталога для класса, который вызывает IHandleMessages, не смогло найти мой класс (хотя сборка была абсолютно там).

Оказывается, если NServiceBus не находит что-то, что обрабатывает сообщение, он THETH ETH AWAY!!!

На мой взгляд, это полная ошибка дизайна. Вся идея NServiceBus заключается в том, чтобы не потерять ваши данные, но в данном случае это именно то, что нужно!

Теперь, когда вы знаете об этой ловушке, есть несколько способов ее обойти.

  1. Четко укажите, каким должен быть ваш обработчик (обработчики):

    NServiceBus.Configure.With().LoadMessageHandlers<First<MyMessageType>>()

  2. Еще одна дополнительная защита заключается в добавлении еще одного обработчика, который будет обрабатывать «Все остальное». IMessage является базой для всех полезных данных сообщений, поэтому, если вы поместите на него обработчик, он соберет все.
    Если вы установите для IMessage значение обработать после обработки ваших сообщений, тогда он будет обрабатывать все, для чего NServiceBus не может найти обработчик. Если вы вызовете исключение и исключение в этом методе Handle, это заставит NServiceBus переместить сообщение в очередь error. (Я думаю, что это должно быть поведением по умолчанию.)

person Vaccano    schedule 21.03.2012
comment
Была ли ваша работа направлена ​​на то, чтобы указать все ваши обработчики сообщений там или только один в сборке обработки сообщений? - person Galen; 10.08.2012
comment
@Galen - у меня есть только один обработчик сообщений. И я прямо указываю, что это сейчас в моем конфиге. - person Vaccano; 10.08.2012