Два потребителя в одной очереди Websphere MQ JMS, оба получают одно и то же сообщение

Я работаю с кем-то, кто пытается добиться балансировки нагрузки, используя очереди JMS с IBM Websphere MQ. Таким образом, у них есть несколько потребителей Camel JMS, настроенных на чтение из одной и той же очереди. Несмотря на то, что это поведение не определено в соответствии со спецификацией JMS (во всяком случае, в прошлый раз, когда я смотрел), они ожидают своего рода поведение циклического перебора/балансировки нагрузки. И хотя спецификация оставляет это неопределенным, я пришел к выводу, что нормальное поведение Websphere MQ заключается в доставке сообщения только одному из потребителей, и что он может выполнять некоторую нагрузку -балансировка. См. здесь, например: MessageConsumer подключается к той же очереди (Websphere MQ), как сбалансировать нагрузку между потребителем сообщений?

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

Может ли кто-нибудь, кто больше разбирается в Websphere MQ, пролить свет на это? Есть ли ситуации, когда такое поведение ожидается? Есть ли какие-либо изменения конфигурации, которые могут облегчить это?

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

Не то чтобы я был сторонником полагаться на что-то неопределенное, но если они готовы полагаться на конкретное поведение IBM, я оставлю это на их усмотрение.


person mindcrime    schedule 17.04.2013    source источник


Ответы (1)


Единственный способ для них обоих получать одни и те же сообщения:

  1. Есть несколько копий сообщения.
  2. Приложения просматривают сообщение без блокировки, а затем возвращаются, чтобы удалить его.
  3. Приложения отменяют транзакцию и снова делают сообщение доступным.
  4. Соединение разрывается до того, как приложение подтвердит сообщение.

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

Если это система для разработчиков, установите SupportPac MA0W и скажите трассировать только эту очередь, и вы сможете увидеть именно то, что происходит.

См. спецификацию JMS в разделе 4.4. Поставщик никогда не должен доставлять вторую копию подтвержденного сообщения. Исключение сделано для обработки сеанса в версии 4.4.13, которую я рассматривал в пункте 4 выше. Это довольно однозначно и является частью официальной спецификации, а не характерным для IBM поведением.

person T.Rob    schedule 17.04.2013
comment
Спасибо Т. Роб. Я не смотрел на реальную спецификацию годами, но я думал, что когда в очереди было несколько потребителей (в отличие от темы), поведение было совершенно неопределенным. Но, возможно, условие никогда не доставлять вторую копию подтвержденного сообщения превосходит это. - person mindcrime; 18.04.2013
comment
Это порядок доставки среди конкурирующих потребителей, который не определен. На доставку сообщений также влияют настройки QOS. Если приложение указывает ленивое подтверждение, оно может получить дубликаты. Но если сообщение поставлено в очередь и подтверждено, а не отменено или иным образом имеет исключение, вы получаете однократную доставку. - person T.Rob; 18.04.2013