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