Websphere MQ: Кто должен управлять очередями

Question

отката

Допустим, что мои детали конфигурации:

• 1 PubSub, публикующий сообщения в теме MQ.
• 2 различных потребительских приложения.
• 1 подписка на тему для каждого потребителя.
• 1 очередь на подписку.
• И, наконец, 1 очередь резервного копирования для каждой очереди.

Кому следует управлять содержимым очереди резервного копирования и определять, что должно быть переиздано?

Answer 1

Первое, на что вам нужно обратить внимание: почему сообщения заканчиваются в резервной очереди в первую очередь?

1) Является ли клиент JMS резервным сообщением, потому что сообщения не в допустимом формате?

2) Является ли это, что потребительское приложение откатывает сообщения из-за ошибки в приложении?

Если проблема № 1 выше, вам нужно посмотреть на приложения-производители и определить, почему формат сообщения недействителен. Если это №2, вам нужно посмотреть на свою логику приложения.

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

Answer 2

Приложение, имеющее очередь резервного копирования, должно всегда управлять резервной очередью. Хотя это верно в общем случае, это особенно справедливо в случае pub/sub, потому что издателю не удается узнать, кто все подписчики, и управлять их резервными очередями по всему имуществу MQ.

Аргумент против этого является то, что конкретный дизайн приложения делает заранее знать получатель сообщений. Мой ответ заключается в том, что в нем описывается список рассылки, а не pub/sub, который был специально разработан для отстранения издателей от подписчиков.

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

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