Сообщения MSerQ NServiceBus периодически застревают в исходящей очереди

Question

У нас есть система Pub / Sub, основанная на NServiceBus, где у нас периодически возникают проблемы с сообщениями, которые застряли в исходящей очереди Publishers на неопределенное время, а не передаются во входные очереди подписчиков.

Очки на заметку:

1. Когда мы перезапускаем службу Publisher Service и Subscriber, поток сообщений некоторое время возобновляется нормально.
2. Проблема возникает чаще, если между сообщениями возникает длительный период времени.
3. Служба издателя находится в локальной сети, а подписчики - на другой стороне брандмауэра.
4. Некоторые сообщения проходят! Как уже упоминалось после перезапуска службы, некоторое время дела идут хорошо.
5. Используя QueueExplorer, я вижу, что сообщения в исходящей очереди находятся в состоянии ОЖИДАНИЯ.

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

Answer 1

Сообщения MSMQ, застрявшие в исходящей очереди, являются чисто проблемой MSMQ.
Перезапуск служб Publisher и Subscriber не должен иметь никакого значения, поскольку они непосредственно не участвуют в доставке сообщений.Если вы можете решить эту проблему, ТОЛЬКО перезапустив службы Pub / Sub, а НЕ службы очереди сообщений, то это похоже на проблему утечки ресурсов / памяти.

Я представляю, что происходит примерно так:

1. Сообщения передаются по назначению, которое использует память ядра для их хранения
2. По какой-то причине память ядра исчерпана (слишком много сообщений, утечка памяти, куда угодно)
3. Адресат теперь отклоняет новыйсообщения, так как они не могут быть загружены в память с провода
4. Соединение сбрасывается и не пересоединяется до достижения значения WaitTime;На этом этапе очередь «ждет»
5. Система перебирает (3) и (4) до тех пор, пока ...
6. Паб / Sub-сервисы не будут перезапущены, и теперь для сообщений достаточно ресурсовдоставлено
7. Goto (2)

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

Пункт 4 этого сообщения в блоге является наиболее вероятным виновником: http://blogs.msdn.com/b/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx

Приветствия
John Breakwell

Answer 2

Просто закинуть 2п:

У нас была проблема, из-за которой служба очереди сообщений имела утечку памяти и потребляла большие объемы памяти, которая не освобождалась.

Это приводит к зависанию сообщений на длительные периоды времени - хотя в конечном итоге они будут доставлены (иногда через 3 дня).

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

Answer 3

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

Я думаю, что нашел ответ здесь, по крайней мере, это решило проблему, с которой я столкнулся:

http://support.microsoft.com/kb/2554746

Кроме того, в моем случае это не имело никакого отношения к перезапуску, так что не позволяйте этому сбить вас с толку, у меня действительно были симптомы в netstat, и сообщения первоначально проходили при первом запуске клиента.

Answer 4

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