Durable Subscriber не получает сообщения от темы - PullRequest
Новая
       2

Durable Subscriber не получает сообщения от темы

1 голос
/ 06 марта 2012

Я использовал подписчик SYSTEM.JMS.D.SUBSCRIBER.QUEUE и идентификатор клиента в качестве setClientID ("USER1") и использовал topicSubscriber = topicSession.createDurableSubscriber (topic, "SUB1");

topicSubscriber создан, и при попытке получить с помощью этой topicSubscriber.receive (); он не получает сообщения из темы, но в теме есть сообщения.

Кто-нибудь может сказать, почему он не получает сообщения и нужно ли мне проверять какие-либо конфигурации очереди.

Любая помощь приветствуется.

Заранее спасибо.

У меня уже была topicConnection.Start () в моем коде, также я проверил в TopicSession, что нет метода Start ().

Тот же код с методом недолговечного подписчика topicSession.createSubscriber (topic); работает, но для длительного пользования он не работает.

Спасибо

Извините, да, я имел в виду topicConnection.Start ().Это стоило проверить.

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

Напримермоя максимальная глубина очереди для очереди SYSTEM.JMS.D.SUBSCRIBER.QUEUE установлена ​​в 100, и если мы проверим нашу текущую глубину очереди и если она достигнет 100, подписчик не будет работать.

Как альтернативный способ iamпытаясь создать с помощью временной темы, здесь я получаю сообщение об ошибке при создании надежного подписчика topicSession.createDurableSubscriber (topic, "SUB1");

Исключение JMS :: javax.jms.InvalidDestinationException: MQJMS0003: пункт назначения не понят или больше не действителен

Может ли кто-нибудь помочь решить эту ошибку.

Заранее спасибо.

1 Ответ

3 голосов
/ 18 июня 2015

Кажется, проблема в том, как вы используете SYSTEM.JMS.D.SUBSCRIBER.QUEUE.Похоже, вы направляете сообщения и подписчиков в эту очередь в качестве места назначения для длительной подписки.IBM MQ использует эту очередь для управления надежными подписками.

Как правило, очереди, имена которых начинаются с SYSTEM, предназначены для внутреннего использования системой MQ.Некоторые из них, такие как SYSTEM.ADMIN.*.EVENT, подходят для получения сообщений, но вы также не будете использовать их в качестве пункта назначения подписки для несвязанных сообщений.

Многие учебники используют SYSTEM.DEFAULT.LOCAL.QUEUE в качестве места назначения для сообщений, но это только потому, что известно, что очередь существует во всех версиях MQ, а MQ использует только определение очереди и никогда содержимое этой очереди.Для автора учебного пособия (и в этом IBM так же виноват) указывать на SYSTEM.DEFAULT.LOCAL.QUEUE, а затем направлять учащегося через необходимость и средства для создания своей собственной очереди.Таким образом, хотя лучшие практики предполагают, что это не должно быть исключением из правила «не использовать SYSTEM объекты», общее использование делает SYSTEM.DEFAULT.LOCAL.QUEUE фактическим исключением.

Другими исключениями, конечно же, являютсяочереди команд для MQ, MFT и IIB.Это также имена SYSTEM.*, но они предназначены для взаимодействия пользователей с программным обеспечением, прослушивающим очередь.

Обратите внимание, что все правила исключения "не использовать SYSTEM объекты" являются интерфейсами между приложениями и системой MQ.Ресурсы.Очереди событий - это MQ, отправляющая информацию пользователю.Очереди команд - это пользователь, отправляющий информацию системным компонентам.Подписка не относится ни к одной из этих категорий.Пункт назначения для подписки считается объектом, принадлежащим приложению, даже если система управляет им от имени подписчика.

Если вы хотите иметь долговременную подписку, либо разрешите системе назначить постоянную очередь и использовать ее,или предварительно определите очередь (которая не называется SYSTEM.*) и используйте ее.Что бы вы ни делали, НЕ пытайтесь перехватить внутренние системные очереди MQ для целей уровня приложения.

...