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

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

Дано:

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

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

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 - адрес машины с очередью.

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

Проблема заключалась в том, что все компьютеры были клонированы VM и имели тот же 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

Ответ 5

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

Ответ 6

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