Потребление и подтверждение сообщений DMLC

Это дополнительный вопрос для Difference между режимом AUTO_ACKNOWLEDGEMENT с Spring JMS и без него.

Я использую DMLC, и число моих одновременных потребителей равно 1. Предел предварительной выборки > 1. Я получил сообщение, и оно подтверждено до выполнения прослушивателя. Таким образом, пока прослушиватель выполняется, у брокера есть больше сообщений, и он отправляет их потребителю в соответствии с настройками предварительной выборки. Поскольку прослушиватель все еще выполняется, как будут работать потребление и подтверждение для последующих сообщений?

Будет ли вызываться метод receive() для всех новых сообщений, будут ли они подтверждены и будут ли они ожидать завершения выполнения слушателя? [Если это так, то я не понимаю, почему я получаю количество неподтвержденных сообщений в статистике потребителей] ИЛИ Будет вызван метод receive(), но следующее сообщение не будет подтверждено до тех пор, пока предыдущий слушатель не завершит свое выполнение? [это потенциально может объяснить неподтвержденные сообщения, если выполнение моего прослушивателя заблокировано по какой-либо другой причине] ИЛИ Что-то еще происходит под капотом.

Может кто-нибудь объяснить это? Это мне очень поможет.

Спасибо и ура!


spring jms spring-jms activemq message-listener
person xabhi    schedule 12.02.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

№ receive() вызывается для получения первого сообщения; это подтверждается при получении возврата; затем поток контейнера вызывает прослушиватель. (Вы должны использовать транзакции с DMLC, если хотите отменить неудачную доставку — если ваш слушатель выдает исключение).

Любые предварительно выбранные сообщения доставляются брокером в клиентскую библиотеку, но Spring не увидит их до тех пор, пока ваш слушатель не выйдет (onMessage()) после обработки предыдущего сообщения. то есть receive() вызывается в том же потоке, что и MessageListener.

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

person Gary Russell    schedule 12.02.2015
comment
Таким образом, это потенциально может оставить неподтвержденные сообщения на стороне брокера сообщений. - person xabhi; 13.02.2015
comment
Только пока ваш слушатель держит ветку; следующее сообщение будет получено/подтверждено, как только будет завершена обработка текущего сообщения. Если вы не хотите видеть неподтвержденные сообщения, не используйте предварительную выборку. - person Gary Russell; 13.02.2015