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

Хотя мой вопрос похож на тот, который уже был найден на SO, этот пост мне не помог, поэтому вот он:

Данный:

  • Две машины в одном сегменте (естественно, в одном домене, фактически на одном столе)
  • Обе машины являются рабочими станциями Windows 7.
  • На обеих машинах отключен брандмауэр.
  • Обе машины видят друг друга (пинг работает)
  • На одном из них есть закрытая очередь нетранзакционных сообщений test.
  • На машине-отправителе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\SimpleClient\@BinaryEnabled = 'Yes'
  • Владелец очереди отправляет сообщение с другого компьютера
  • Сообщение застревает в очереди исходящих сообщений и не достигает адресата.
  • При отправке с той же машины (т. Е. Локально) сообщение приходит нормально.

Сообщение отправляется с использованием следующего кода:

var q = new MessageQueue(@"FormatName:Direct=OS:il-mark-lap\private$\test");
q.Send(string.Format("Test message sent at {0} from {1}", DateTime.Now, Environment.MachineName));

Где il-mark-lap - адрес машины с очередью.

Что, черт возьми, мне нужно сделать, чтобы эта штука заработала?

Большое спасибо.


person mark    schedule 28.10.2010    source источник
comment
Я столкнулся с той же проблемой. Марк, ты когда-нибудь разбирался в этом?   -  person user923849    schedule 01.09.2011
comment
Сейчас не припомню. В любом случае, у msmq есть миллионы проблем, поэтому мы просто отказались от него. Мой совет - держитесь от этого подальше.   -  person mark    schedule 01.09.2011
comment
Я добавил награду, так как у нас та же проблема. Сообщения просто попадают в очередь исходящих сообщений, даже если используется DIRECT = TCP.   -  person 79E09796    schedule 31.05.2012
comment
Мы давно отказались от MSMQ из-за всех связанных с ним проблем. Мой совет - следуйте их примеру.   -  person mark    schedule 31.05.2012
comment
Спасибо за совет. Поскольку никто не мог помочь даже с наградой, мы также отказались от MSMQ в пользу RabbitMQ.   -  person 79E09796    schedule 11.06.2012


Ответы (6)


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

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

person BlackICE    schedule 21.12.2011

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

Получите утилиту DTCPing от Microsoft, запустите ее На машинах, использующих MSMQ, коды DTC должны иметь возможность взаимодействовать друг с другом, чтобы MSMQ работал.

Устранение неполадок MSDTC с помощью инструмента DTCPing

Это, в свою очередь, заставило меня понять, что MSMQ сильно зависит от имен NetBIOS - машины должны иметь возможность проверять связь друг с другом, используя только имена NetBIOS.

После этого убедитесь, что вы перезапустили ВСЕ службы очереди сообщений (как на отправляющем, так и на целевом компьютере, поскольку он должен иметь возможность выполнять обратную операцию NetBIOS).

В моем случае, как только я запустил DTC с разрешением имени NetBIOS - перезапустил службы - все начало работать волшебным образом.

Я настоятельно рекомендую вам посетить эту страницу для получения дополнительных ресурсов.

person Karell Ste-Marie    schedule 22.10.2012
comment
Мы давно отказались от MSMQ (хорошо), .NET (так себе) и C # (вздох) в пользу Java (:-(). Но все равно спасибо. - person mark; 23.10.2012
comment
Для меня это было убедиться, что обе машины могут пинговать друг друга, используя имя NetBIOS. Спасибо - person xhafan; 13.07.2017

У меня была эта проблема сегодня. Чтобы решить эту проблему, нам пришлось открыть диалоговое окно свойств очереди сообщений принимающего сервера и на вкладке «Безопасность сервера» снять флажок «Отключить неаутентифицированные вызовы RPC». Также в частной очереди Properties | На вкладке «Безопасность» мы изменили безопасность, чтобы предоставить всем полный доступ. В моем случае машины находятся в одном сегменте, но не в одном домене. Очередь не транзакционная. Мы используем IP-адреса для привязки конечных точек (WCF), NetBIOS / DNS не используется.

person GrokSrc    schedule 15.02.2013
comment
Спасибо. После нескольких часов попыток решить аналогичную проблему (однако мой MSMQ был общедоступным и транзакционным) больше ничего не помогло. Отключить неаутентифицированные вызовы RPC было исправлением. - person geedubb; 13.11.2013
comment
Мы видели ту же проблему. Отключить неаутентифицированные вызовы RPC проверено. Снятие отметки с этой опции позволило обойти проблему. Мы подозреваем, что основная причина - какое-то изменение уровня сети, но это изменение сразу заставило нас работать. Все исходящие очереди мгновенно отправили свои сообщения в очереди назначения. - person Paul Williams; 22.04.2016

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

Проблема заключалась в том, что все компьютеры были клонированными виртуальными машинами и имели одинаковый QMId в разделе реестра: HKLM \ Software \ Microsoft \ MSMQ \ Parameters \ Machine Cache. Мы переустановили MSMQ на серверах, что устранило проблему.

Использованная литература:

http://baleinoid.com/whaly/2012/08/random-bug-msmq-unacknowledged-messages/ http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx

person David Fidge    schedule 29.06.2015
comment
Это помогло мне, спасибо! - person Martin; 05.01.2018

Ответ очень прост. Убедитесь, что вы можете использовать telnet-порты 1801, 135, 2103 и 2105 как с исходного компьютера, так и с конечного компьютера и наоборот. Также убедитесь, что MSMQ запущен на обеих машинах.

person mugume david    schedule 05.11.2012

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

person log111    schedule 10.03.2011
comment
исходящие очереди создаются всегда. - person BlackICE; 21.12.2011