Have the following scenario:

Using MQ v5.3 csd5.
I disconnect a machine from the network hosting a queue manager
which supports a clustered queue.  I then put a message to that
clustered queue from elsewhere in the cluster.  I monitor the
status of the active channels on the queue manager that will transmit
the message to the disconnected node.  The cluster sender channel
goes to binding and stays in that state for a long period of time
before going into a retrying state.

I reconnect the machine and leave the queue manager stopped.
I resend the message and the cluster sender goes binding and then
in short order goes into retrying.

I then do the same thing using a sender channel.  With the target
machine disconnected I send a message and the status of the sender
channel goes to binding followed in short order by retrying.

It seems that with cluster sender channels the presence of the target
queue manager tcpip address makes a difference to how long it stays
in a binding state.  A sender channel seems to be uneffected by
the presence or absence of the target tcpip address.

This would be of interest if the program doing the put specifies
MQC.MQOO_BIND_NOT_FIXED.  The message is placed on the cluster
transmit queue and sits there until the cluster sender channel
goes into a retrying state at which time it will be sent to another
instance of the cluster queue.  In my case I've set up a cluster exit
(one of sample programs distributed with MQ) which first sends messages
to a specific queue manager and then fails over to any remaining
queue managers hosting an instance of the clustered queue.  While
the binding state is in effect the queue depth of the transmit queue
grows and the messages will not be forwarded on to other active
queue managers hosting an instance of queue.  This is why the time
needed to get to a retrying state is important.

Does anyone have any insight into this?

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Reply via email to