SimpleMessageListenerContainer подписывается на несколько очередей с помощью RetryOperationsInterceptor - PullRequest
0 голосов
/ 17 октября 2018

Я играю с SimpleMessageListenerContainer, который подписан на 3 разные очереди.SimpleMessageListenerContainer был настроен с RetryOperationsInterceptor, который имеет экспоненциальную политику отката.

Мой SimpleMessageListenerContainer был настроен с:

container.addQueueNames("news.politics","news.science","news.tech");
container.setMaxConcurrentConsumers(10);
container.setAdviceChain(new Advice[]{retryInterceptor});

Если сообщение из одной из 3 очередей было использовановходит в ошибочное состояние, приводящее к исключению, потребитель запускает экспоненциальную обратную сторону политики, как и предполагалось.Тем не менее, я заметил, что потребитель перестает делать циклический перебор для обработки сообщений в двух других очередях.Я думал, так как для потребителя установлено значение «MaxConcurrentConsumer», равное 10, потребитель начнет порождать потоки потребителя и циклически перебирать оставшиеся очереди.

  1. Это нормальное поведение SimpleMessageListenerContainer?
  2. Можно ли настроить это поведение?
  3. Для моего варианта использования было бы рекомендовано иметь один SimpleMessageListenerContainer на очередь, чтобы сохранить их сегрегацию?Возможно, придумаете декоратор CompositeSimpleMessageListener контейнер, который имеет внутреннюю карту SimpleMessageListenerContainers для каждой очереди?

1 Ответ

0 голосов
/ 17 октября 2018

Алгоритм увеличения потребителей ограничен;если перехватчик повторных попыток приостанавливает поток потребителя, это предотвратит запуск новых потребителей.

Либо увеличьте значение concurrentConsumers (по крайней мере до 3), либо переключитесь на DirectMessageListenerContainer.См. Выбор контейнера .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...