Spring JMS Design Вопрос: разделение обработки сообщений

Question

Я использую прослушиватель сообщений для обработки некоторых сообщений из MQ на основе SpringMessageListenerContainer. После того, как я получил сообщение, мне нужно сделать вызов веб-службы (WS). Однако я не хочу делать это в методе onMessage, потому что он будет блокировать метод onMessage до тех пор, пока вызов WS не будет успешным, и это приводит к задержке при удалении сообщений из очереди. Как можно отделить вызов веб-службы, вызвав его вне метода onMesage или не оказав влияния на удаление сообщений из очереди?

Спасибо

Answer 1

Я думаю, что вы действительно хотите вызвать веб-сервис из своего onMessage. Почему вы хотите быстро удалить сообщения из очереди, а затем отложить дальнейшую обработку? Если вы делаете то, что говорите, вам, вероятно, придется ввести другой уровень очередей или какое-то временное «удержание» коллекции, которая является избыточной. Суть очереди в том, чтобы удерживать сообщения, а ваш прослушиватель сообщений извлечет их и обработает как можно быстрее.

Если вы ищете способ максимизировать пропускную способность в очереди, вы можете подумать о том, чтобы сделать ее многопоточной, чтобы у вас было несколько потоков, извлекающих сообщения из очереди для вызова веб-службы. Вы можете легко сделать это, установив конфигурацию «concurrentConsumers» в DefaultMessageListenerContainer. Если вы установите для concurrentConsumers значение 5, у вас будет 5 потоков, вытягивающих сообщения из очереди для обработки. Это действительно сложно, если вам нужно поддерживать порядок сообщений, но в этом случае могут быть решения этой проблемы.

Answer 2

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

У нас есть что-то похожее в одном рабочем процессе, где, если пользователь выбирает какую-либо опцию XYZ в графическом интерфейсе, это означает, что на сервере нам нужно подключиться к другому внешнему веб-сервису, чтобы получить ABCD, в этом случае мы не выполняем вызов веб-сервиса в onMessage Thread и используем ThreadPool для отправки и обработки этого вызова.

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

надеюсь, это поможет.