MSMQ Poison сообщение и TimeToReachQueue - PullRequest
0 голосов
/ 12 февраля 2012

Я попытался создать сценарий ядовитого сообщения следующим образом.

1 - Создана очередь сообщений на сервере (транзакционная очередь).2- Создано приложение получателя, которое обрабатывает входящие сообщения на этом сервере.3- Создано клиентское приложение, расположенное на клиентском компьютере, которое отправляет на этот сервер сообщения с определенным именем для очереди.

4- Я использовал клиентское приложение отправителя со следующим кодом (платформа C # 4.0):

System.Messaging.Message mm = new System.Messaging.Message("Some msg");
mm.TimeToBeReceived = new TimeSpan(0, 0, 50);
mm.TimeToReachQueue = new TimeSpan(0, 0, 30);
mm.UseDeadLetterQueue = true;

mq.Send(mm);

Таким образом, это устанавливает тайм-аут для достижения очереди в 30 секунд.

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

В очереди сообщений на клиентском компьютере я вижу, что сообщение ожидает отправки («Ожидание соединения»).Моя проблема заключается в том, что, когда оно превышает 30 секунд (или 50 секунд), сообщение никогда не попадает в очередь недоставленных сообщений на клиентском компьютере.

Почему это так?... Я ожидал, что это произойдет по истечении некоторого времени ожидания.

Протестировано на Windows 7 (клиент) / Windows server 2008 r2 (сервер)

1 Ответ

0 голосов
/ 22 февраля 2012

Вашему вопросу уже несколько дней. Вы что-нибудь узнали?

Моя интерпретация вашего сценария заключается в том, что отключенный кабель является ключом.

В сценарии, описанном Джоном, существует существующее соединение , и получатель не может правильно обработать сообщение в течение установленного срока.

Однако в вашем сценарии принимающая конечная точка никогда не получает возможности обработать сообщение, поэтому время ожидания может не наступить. Как вы сказали, состояние сообщения Waiting for connection. Сообщение, которое было никогда не отправлено не может логически иметь время ожидания для достижения пункта назначения .

Просто спросите себя, сколько ресурсов Windows / MSMQ без необходимости пожертвует - и как часто - чтобы проверить MessageQueues на сколько условий, если очереди по существу неактивны ? В системе может быть много очередей с большим количеством сообщений.

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

Возможно, вы захотите проверить этот сценарий - или вы уже проверили его в это время?

...