Тайм-аут JMS или TimeToLive - PullRequest
Новая
       26

Тайм-аут JMS или TimeToLive

2 голосов
/ 23 сентября 2011

Я довольно новичок в Java EE и JMS и собираюсь сделать реализацию с использованием JMS.

Подумайте о следующем сценарии:

Сценарий

Пользователь нажимает сервлет.Затем сообщение помещается на сервер / очередь JMS из этого сервлета.Затем пользователю отправляется ответ с сообщением «Очередь сообщений».

Опция 1

Потребитель / MDB получает сообщение из очереди JMS и обрабатывает его.Это нормальная работа и довольно стандартная.

Вариант 2

Нет потребителя (по какой-либо причине) или получатель обрабатывает сообщения слишком медленно.Так что я хотел бы, чтобы сообщение в очереди находилось в режиме ожидания.После истечения времени ожидания и отправки электронной почты и т. Д. (Электронная почта приведена в качестве примера).

Чтение спецификации API / учебника Java EE 6, которое я нашел в классе QueuSender 

void send(Message message, int deliveryMode, int priority, long timeToLive)

По настройкам timeToLive сообщение будет удалено из очереди.Проблема в том, что нет интерфейса / обратного вызова, чтобы знать, что сообщение было удалено.Это просто исчезает.Или я ошибаюсь?

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

Любой свет, проливаемый по этому вопросу, был бы очень признателен.

Ответы [ 2 ]

1 голос
/ 23 сентября 2011

Вы должны использовать некоторые функции, специфичные для реализации, чтобы удовлетворить ваши требования.Спецификация JMS не определяет, какое действие предпринимается с сообщением с истекшим временем ожидания, и не предлагает разумного выбора критериев при опросе сообщений из очереди.

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

Итак,если вы установите две очереди, Q1 и Q2, и сконфигурируете Q2 как DLQ для Q1, вы выполните обычную обработку запросов в слушателе на Q1 и реализуете дополнительный прослушиватель для Q2 для обработки ошибок / тайм-аутов.

0 голосов
/ 31 октября 2013

Синхронное взаимодействие через JMS также может вам помочь. В основном на стороне клиента вы:

  1. отправить сообщение с идентификатором корреляции и временем жизни
  2. получить сообщение (обычно в одной и той же цепочке) с тем же идентификатором корреляции и указанием времени ожидания (time-to-live == timeout, поэтому, если вы обработаете его как мертвое, оно действительно мертвое)

С другой стороны, сервер:

  1. при входящем сообщении должен получить идентификатор корреляции
  2. укажите идентификатор корреляции для ответа при отправке его клиенту. Конечно, сервер должен быть достаточно быстрым, чтобы соответствовать порогу тайм-аута / времени жизни.

Таким образом, на стороне клиента вы всегда уверены, что произошло с отправленным сообщением.

...