Можно ли перенести идентификатор клиента подписчика JMS на хосты? - PullRequest
2 голосов
/ 14 марта 2011

У меня есть задача с постоянным подписчиком на тему JMS, и мне нужно иметь возможность перемещать эту задачу с одного хоста на другой.

Задача установила свой идентификатор клиента с помощью:

TopicConnection.setClientID ( "MyClient");

и

TopicSession.createDurableSubscriber (Тема, "Прочный");

Для соответствующих экземпляров TopicConnection, TopicSession и Topic. Я использую подтверждение клиента, и каждое сообщение подтверждается после успешной обработки (в приведенном ниже примере выполнения ошибок не было).

У задачи всегда будет один и тот же идентификатор клиента (комбинация «MyClient» и «durable»).

Однако создается впечатление, что этот же идентификатор клиента рассматривается как отдельный для каждого хоста.

Итак, я получаю следующий сценарий:

  1. На хосте А работает подписчик.
  2. Отправляются сообщения 1-10.
  3. Хост A получает сообщения 1-10 и отключает своего абонента (закрывая соединение)
  4. Отправляются сообщения 11-20.
  5. Хост B устанавливает подписчика с (очевидно) тем же идентификатором клиента
  6. Отправляются сообщения 21-30.
  7. Хост B получает сообщения 11-30 (и часто несколько предыдущих сообщений, казалось бы, наугад)
  8. Хост B отключает своего абонента
  9. Хост A снова настраивает своего абонента
  10. Хост А получает сообщения 11-30

Прав ли я, полагая, что идентификатор хоста каким-то образом включается в идентификатор клиента под капотом? И есть ли способ остановить это?

Я использую SwiftMQ, если такое поведение присуще этому решению.

Ответы [ 2 ]

1 голос
/ 14 марта 2011

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

0 голосов
/ 15 марта 2011

Хорошо, мы выяснили, почему это происходит.

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

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