Блог

Настройка потребителя CMS с помощью слушателя включает в себя два отдельных вызова: во-первых, получение потребителя:

  cms::MessageConsumer* cms::Session::createConsumer( const cms::Destination* );
  

и затем, установив прослушиватель на потребителе:

 void cms::MessageConsumer::setMessageListener( cms::MessageListener* );
  

Могут ли сообщения быть потеряны, если реализация подписывается на адресата (и получает сообщения от брокера / маршрутизатора) до активации прослушивателя? Или такие сообщения помещаются в очередь внутри и доставляются слушателю при активации?

Почему нет вызова API для создания потребителя с слушателем в качестве конструктивного аргумента? (Это потому, что в спецификации JMS его нет?)

(Дополнение: это, вероятно, недостаток в самом API. Более логичным порядком было бы создать экземпляр потребителя из сеанса и иметь cms::Consumer::subscribe( cms::Destination*, cms::MessageListener* ) метод в API.)

Я не думаю, что API обязательно испорчен. Очевидно, что это могло быть разработано по-другому, но я считаю, что решение вашей предполагаемой проблемы исходит от start метода Connection объекта (унаследованного через Startable ). Документация для Connection состояний:

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

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

Соединение может быть запущено немедленно, а настройка может быть выполнена впоследствии. Клиенты, которые делают это, должны быть готовы обрабатывать асинхронную доставку сообщений, пока они все еще находятся в процессе настройки.

Это тот же шаблон, которому следует JMS.

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

Если вы хотите добавить потребителей после того, как вы уже вызвали start() , вы, конечно, можете stop() сначала позвонить, но я не вижу никаких проблем с простым добавлением их на лету.