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

Question

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

Очки отметить:

1. Когда мы перезапустить службу издателя и подписчиков услуги, поток сообщений возобновляется обычно на некоторое время.
2. Проблема возникает чаще, если происходит продолжительный промежуток времени между сообщениями.
3. Служба издателя находится в локальной сети, подписчики на другой стороне брандмауэра.
4. Некоторые сообщения проходят! Как упоминалось после перезагрузки службы, все идет хорошо.
5. Используя QueueExplorer, я вижу, что сообщения в исходящей очереди имеют состояние WAITING.

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

Answer 1

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

Я представляю себе что-то вроде этого происходит:

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

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

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

Приветствия
Джон Breakwell

Answer 2

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

Answer 3

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

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

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

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

Answer 4

Просто бросить мой 2р в:

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

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

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