Как обработать порядок сообщений в JMS?

Question

Я рассматриваю клиент-серверное приложение, написанное на Java. Сервер принимает сообщения JMS и обрабатывает их, но сообщения могут приходить в непредвиденном порядке, и перед сообщением заказа может прийти отмена Как вы справляетесь с таким случаем? Вы делаете это в MDB?

Какие существуют стратегии или шаблоны для такого сценария?

Answer 1

Насколько я знаю, это называется доставкой «вне очереди» и является частью атрибутов качества обслуживания (QoS) системы JMS. Я не думаю, что это является частью спецификации JMS, но некоторые провайдеры поддерживают это, может быть. Это будет зависеть от конкретной используемой вами реализации JMS.

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

Википедия говорит это лучше меня:

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

Запрос на внеплановую отмену нелегко выполнить с помощью JMS. Две идеи:

• Хранить тикет, который соответствует каждому сообщению в базе данных, можно легко для отмены сообщения. Когда сообщение доставлено, MDB проверяет, действителен ли соответствующий билет. Если да, то продолжите, если нет, отбросьте сообщение.
• Попробуйте установить размер пула MDB в единицу. Возможно, в этом случае доставка будет заказана. Изменение размера пула - приложение. зависит от сервера, но большинство из них поддерживает размер пула для каждого компонента.

В противном случае, возможно, посмотрите на хранилище сообщений . В любом случае стоит проверить сайт EAI .

Answer 2

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

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

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

Answer 3

Я второй совет о проверке сайта EAI и книги, на которой он основан (фантастический текст о MOM и шаблонах MOM).

Лично я бы исследовал Resequencer Впрочем.

Answer 4

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