Как обработать порядок сообщений в JMS?
Я рассматриваю клиент-серверное заявление, записанное в Java. Сервер получает сообщения JMS и обрабатывает их, но сообщения могут существовать неожиданного порядка, и отмена может прибыть перед сообщением порядка. Как Вы обрабатываете такой случай? Вы делаете это в mdb?
Каковы некоторые стратегии или шаблоны для этого вида сценария?
3 ответа
Насколько я знаю, это называется доставкой "не по порядку" и часть атрибутов качества обслуживания (QoS) системы JMS. Я не думаю, что это часть спецификации JMS, но, возможно, какой-то провайдер ее поддерживает. Это будет зависеть от конкретной реализации JMS, которую вы используете.
Однако обратите внимание, что JMS предназначена для рассылки сообщений нескольким потребителям таким образом, чтобы распределить нагрузку. Если сообщение должно быть доставлено упорядоченным образом, это невозможно - это в основном приводит к сериализации доставки сообщения, и сообщение не может обрабатываться одновременно.
В википедии сказано лучше, чем у меня:
Очередь JMS Промежуточная область, содержащая сообщения, которые были отправлены и ожидают отправки читать. Обратите внимание, что вопреки тому, что предлагает очередь имен , сообщения не обязательно доставлять в том порядке, в котором они были отправлены. Если пул bean-компонентов , управляемый сообщениями, содержит больше , чем один экземпляр, то сообщения могут обрабатываться одновременно, и, таким образом, возможно, что более позднее сообщение будет {{1 }} обрабатывается раньше, чем предыдущее. Очередь JMS гарантирует только то, что каждое сообщение обрабатывается только один раз.
В таком случае запрос отмены по внеполосному каналу нелегко реализовать с помощью JMS. Две идеи:
- Сохранение билета, соответствующего каждому сообщению в базе данных, может быть использовано для простой отмены сообщения.Когда сообщение доставлено, MDB проверяет, действителен ли еще соответствующий билет. Если да, продолжить, если нет, опустить сообщение.
- Попробуйте установить размер пула MDB равным единице. Может быть, в этом случае доставка будет заказана. Изменение размера пула - приложение. зависит от сервера, но большинство из них поддерживает размер пула компонентов.
В противном случае, возможно, взгляните на шаблон хранилища сообщений . В любом случае стоит заглянуть на сайт EAI .
Ваша система станет намного более гибкой, если она сможет справиться с сообщения порядка. Шаблон, который я использовал для решения этой проблемы в прошлом, заключается в использовании очереди задержки (в системе, которая обрабатывала 8 миллионов сообщений в день в финансовом мире).
В вашем примере, если я получил удаление еще не полученного заказа, я бы отложил его на некоторое время и повторил попытку. Если бы я все еще ничего не знал о порядке, который меня просят удалить, я бы вызвал какую-то ошибку (ответ первоначальному отправителю, отправка сообщения в специальную очередь ошибок, ...).
Что касается реализации очереди задержки, это может быть другая очередь JMS со службой, которая может принимать сообщения для задержки. Затем он периодически считывает отложенные сообщения и проверяет, истек ли время задержки, и повторно отправляет сообщение в исходную целевую очередь.
Я поддерживаю совет о проверке сайта EAI и книги, на которой он основан (фантастический текст о MOM и паттернах MOM).
Лично я бы исследовал Resequencer , однако.