Стратегии хранения и блокировки сообщений в очереди с одним потребителем, скрывающим несколько пользователей

Question

Я пытаюсь реализовать следующий сценарий, и я мог бы действительно использовать и ценить некоторую помощь.Я использую ActiveMQ 5.14 с верблюдом 2.21.

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

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

Есть ли у вас какие-либо предложения о том, как будет выглядеть жизнеспособное решение этой проблемы?

edit: больше подробностей, чтобы прояснить ситуацию

Приложение связывается с клиентами посредством предоставления REST API в Интернете с помощью двух вызовов: GET и DELETE .
GET извлекает следующее сообщение из очереди, а DELETE удаляет сообщение из очереди.Мне нужно убедиться, что сообщение выбирается только один раз за определенный период времени и что оно возвращается в очередь, если клиент не отправляет запрос DELETE.В настоящее время у меня есть маршрут от службы отдыха к bean-компоненту, который выбирает сообщение из очереди, возвращает его в запрос GET и после отправляет его обратно в очередь.По запросу DELETE я удаляю сообщение из очереди с заданным идентификатором.Мне все еще нужно найти способ обеспечить доступ к последнему полученному сообщению в течение определенного периода времени.

Answer 1

Я немного запутался в части с неразличимыми машинами, но я понял следующее:

• У вас 1 очередь с сообщениями
• У вас 1 потребитель
• Потребитель принимает сообщение и вызывает услугу или подобное
• Если вызов успешен, сообщение может быть удалено
• Если вызов не удался, сообщение необходимо повторно обработать

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

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

Это поведение более или менее является поведением по умолчанию, если

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

РЕДАКТИРОВАТЬ

На основании ваших разъяснений я понимаю, что это наоборот, чем я предполагал.

Ну тогда я бы, вероятно, увидел два типа запросов как "шаги рабочего процесса", так как они запускаются клиентами.

GET

• Использовать сообщение, отправить его запрашивающей стороне
• Добавить отметку времени в заголовок сообщения
• Отправитьсообщение в другую очередь (назовем его delievered)

УДАЛИТЬ

• Удалить сообщение из delievered очередь

Не удаленные сообщения

• Используйте заголовок отметки времени и селекторы сообщений , чтобы использовать не удаленные сообщения послеопределенное количество времени
• Переместить их обратно в исходную очередь

Со второй очередью у вас есть различные преимущества

• Обрабатываемые сообщения не могут быть снова использованыи, следовательно, не нужно «блокировать»
• Исходная очередь содержит только ожидающие сообщения, delievered очередь только сообщений в обработке
• Вы можете увеличить приоритет сообщений при отправке не удаленных сообщений обратно в источникочередь, поэтому они быстро потребляются
• Вы также можете добавитьзаголовок unter при отправке не удаленных сообщений обратно в исходную очередь, чтобы идентифицировать сообщения, которые были сбойны несколько раз, и обработать их другим способом.