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

Хотя мой вопрос похож на некоторые из них уже нашли на SO, тем пост не помог мне, так вот она:MSMQ сообщения задерживаются в очереди исходящих

Дано:

Две машины на тот же сегмент (естественно, в том же домене, на самом деле на том же столе)
Обе машины Windows 7 рабочих станций
Обе машины отключили брандмауэр
Обе машины видят друг дру er (ping works)
На одном из них есть приватная непроцессуальная очередь сообщений 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));

Где иль маркировочный круг является адрес машины с очередью.

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

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

источник

2010-10-28 mark

Я сталкиваются с той же проблемой. Марк, ты когда-нибудь понял это? – user923849

Теперь я не помню. В любом случае msmq имеет проблемы с gazillion, поэтому мы просто отказались от него. Мой совет - держаться подальше от него. – mark

Я добавил щедрость, поскольку у нас та же проблема. Сообщения просто сидят в исходящей очереди, даже при использовании DIRECT = TCP. – 79E09796

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

источник

2011-03-10 15:39:54 log111

исходящие очереди всегда создаются. – BlackICE

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

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

источник

2011-12-21 14:24:36 BlackICE

Мы давно решили отказаться от MSMQ. Но все равно спасибо. – mark

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

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

Troubleshooting MSDTC issues with the DTCPing tool

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

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

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

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

источник

2012-10-22 20:54:56

Мы давно отказались от MSMQ (хорошо), .NET (so so so) и C# (sigh!) В пользу Java (:-(). Но, во всяком случае, спасибо. – mark

Для меня это должно было убедиться, что обе машины могут пинговать THX – xhafan

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

источник

2012-11-05 18:11:08

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

источник

2013-02-15 19:43:59 GrokSrc

Благодаря часам, пытающимся решить подобную проблему (мой MSMQ был общедоступным и транзакционным), ничего больше не помогло. «Отключить вызовы RPC без аутентификации» было исправлено. – geedubb

Мы видели ту же проблему «Отключить неаутентифицированные вызовы RPC» был отмечен. Отмена проверки этого параметра обошла эту проблему. Мы подозреваем, что основная причина - это изменение уровня сети, но это изменение заставило нас работать немедленно. Все исходящие очереди мгновенно отправили свои сообщения в их целевые очереди. –

У меня была проблема, когда у нас было 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

источник

2015-06-29 05:50:13

Это помогло мне, спасибо! – Martin

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

ответ

Смежные вопросы