2
votes

I see a scenario when an applications puts a message to a topic on the same server, messages get stuck in the transmit queue until i start the channel or drop a test messages (using "amqsput" ) to the queue manager where this messages has to go. After this channels are started or in running state, messages put to the topic are flowing properly. After few hours or a day when no channels are running , when the application drops a message to topic it again stuck in transmit queue until i execute the above drill.

This is in a clustered environment. MQv7.0.1.6

Why messages has to stuck in trasnmit queue even though the remote MQ's are running fine ? This scenario is occurring only when the application publish messages to topic.

1
when you say channel is not running, do you mean channel is stopped or it's just inactive?nitgeek
not stoppped. It is just inactiveVignesh

1 Answers

3
votes

Updated 23 Jan 2014
IBM has replied to my PMR as a match for IV21703: A WMQ V7 CLUSSDR CHANNEL IS NOT STARTED WHEN PERSISTENT PUB/SUB MESSAGES ARE PUT TO CLUSTERED TOPICS.

Error description

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.

Local fix

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

The fix was in 7.0.1.10 and 7.1.0.2 but 7.5 is not mentioned in the APAR. A temporary fix is available for 7.5.0.0 and above. It is targeted for inclusion in FP7.5.0.3 which is due in 1Q14.

The previous answer based on cluster name resolution turned out to be completely wrong. It was a workable theory, but wrong nonetheless. I've deleted it.