2014-01-14 5 views
2

Я вижу сценарий, когда приложения помещают сообщение в тему на том же сервере, сообщения застревают в очереди передачи, пока я не запустил канал или не сбросил тестовые сообщения (используя «amqsput») в диспетчере очередей, куда должны идти эти сообщения. После запуска или запуска этих каналов сообщения, помещенные в тему, текут правильно. Через несколько часов или в день, когда никакие каналы не запущены, когда приложение отбрасывает сообщение, чтобы повторить его, он снова застрял в очереди передачи, пока я не выполнил вышеуказанное упражнение.Websphere MQ - Сообщения, опубликованные в теме, застревают в очереди передачи

Это в кластерной среде. MQv7.0.1.6

Почему сообщения должны застревать в очереди trasnmit, даже если удаленные MQ работают нормально? Этот сценарий возникает только тогда, когда приложение публикует сообщения в теме.

+0

, когда вы говорите, что канал не работает, вы имеете в виду, что канал остановлен или он просто неактивен? – nitgeek

+0

не останавливается. Он просто неактивен – Vignesh

ответ

3

Обновлено 23 янв 2014
IBM ответила на мой PMR в матче за IV21703: A WMQ V7 CLUSSDR CHANNEL IS NOT STARTED WHEN PERSISTENT PUB/SUB MESSAGES ARE PUT TO CLUSTERED TOPICS.

Описание ошибки

When messages are put to cluster queues in syncpoint the cluster 
channels are not started until the application calls MQCMIT; 
the CLUSSDR channels to all the queue managers which are 
destinations for messages put in the Unit of Work are started 
during commit processing. 

This operation does not appear to be carried out when 
publications are put to remote cluster subscriber queues at the 
commit of the internal Unit of Work, that is, the cluster 
channels associated with the put of the subscriber messages are 
not started at that time. The channels are held in the queue 
manager's memory associated with the connection, and are 
started when the application is disconnected and the connection 
is closed. 

Локальное исправление

There are 4- 
1. Change PMSGDLV to ALLAVAIL 
2. Change the messages to non-persistent 
3. Change the CLUSRCVR channels to DISCINT(0) 
4. Call MQDISC after putting msgs to a clustered topic 

Исправление было в 7.0.1.10 и 7.1.0.2, но 7,5 не упоминается в APAR. Временное исправление доступно для 7.5.0.0 и выше. Он предназначен для включения в FP7.5.0.3, который должен быть представлен в 1Q14.

Предыдущий ответ, основанный на разрешении имен кластеров, оказался совершенно неправильным. Это была работоспособная теория, но, тем не менее, неправильная. Я удалил его.

+0

Привет, Роб, я пробовал описанный выше сценарий, я добавил еще двух подписчиков, где цель - локально заданная удаленная очередь указывает на очередь на удаленном диспетчере очередей. Я не вижу разницы. Даже для сообщений, ожидающих очереди передачи, я мог видеть, что значения RemoteQmgr и RemoteQ установлены. – Vignesh

+0

ОК, это звучит как ошибка WMQ. Я посмотрю, смогу ли я заставить своего клиента открыть PMR. Возможно, вы захотите сделать то же самое. –

+0

Хорошо .. Спасибо. Роб. Я отправлю PMR. – Vignesh

Смежные вопросы