Что происходит, если сообщение откатывается в MQ? - PullRequest
Новая
       10

Что происходит, если сообщение откатывается в MQ?

6 голосов
/ 26 мая 2009

Я получаю сообщение из очереди WebSPhere MQ. Я пытаюсь обработать, и если я получаю некоторые исключения, я хочу откатить сообщение в очередь MQ.

У меня нет проблем с тем же. Что происходит с сообщением? Идет ли он в конец очереди?

Если я попытаюсь вытащить сообщение из очереди, получу ли я то же сообщение, что и откат?

Какое поведение может быть? Я хочу знать это поведение, как правило, в сценарии очереди большого объема?

Цените любые входные данные.

Спасибо, Manglu

Ответы [ 3 ]

7 голосов
/ 26 мая 2009

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

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

Эти устройства чтения и записи будут вставлять элементы в очередь или удалять элементы из очереди транзакционно, пока ваша обреченная транзакция разрешается. В этом случае другие элементы очереди могут появляться или исчезать (или оба).

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

4 голосов
/ 26 апреля 2010

Чтобы ответить на пару конкретных моментов из этой темы ...

  • Сообщение сохраняет свою позицию в очереди. GET в syncpoint блокирует сообщение, но не удаляет его из очереди и не меняет его позицию. Откат снимает блокировку и делает сообщение доступным для повторной доставки.
  • Автоматическая пересылка подозрительного сообщения происходит с классами JMS и XMS, но не с API-интерфейсами Java, C, C #, COBOL и т. Д. Если вы не используете JMS или XMS (которая реализует API-интерфейс JMS для программ на C и .Net), вам необходимо перезапустить сообщение самостоятельно.
  • Вы правы в том, что запрос будет выполнен в очереди, указанной в атрибуте BOQNAME входной очереди после превышения количества доставок BOQTHRESH. Если эта очередь недоступна (полная, неавторизованная, несуществующая и т. Д.), То выполняется попытка DLQ. Если это не удается, прослушиватель сообщений полностью прекращает прием сообщений.
  • В идеале программа будет обрабатывать подозрительное сообщение, запрашивая его и предупреждая о наличии сообщений в очереди исключений. В противном случае, по крайней мере, не просто потреблять и отбрасывать сообщение. Записывайте его вместе с заголовками сообщений, чтобы позже кто-нибудь смог согласовать то, что с ним произошло.
4 голосов
/ 03 июня 2009

Откат оставляет сообщение в очереди и помещает его для повторной доставки.

Однако, когда (настраиваемый) лимит попыток повторной доставки достигнут, сообщение откладывается в «очередь недоставленных сообщений».

Типичным примером, где это происходит, является s.c. «ядовитые сообщения»: сообщения, с которыми невозможно разобраться из-за фундаментальных и не преходящих проблем (таких как неправильный формат, пропущенные поля и т. д.).

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

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

НТН

Guy

...