Author |
Message
|
hilltops |
Posted: Thu Apr 05, 2007 6:23 am Post subject: Delivery of message in a multi queue manager MQ cluster. |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
I am concerned about messages getting stuck on the SYSTEM.CLUSTER.TRANSMIT.QUEUE due to the presence of one/more undeliveable(s) on the SYSTEM.CLUSTER.TRANSMIT.QUEUE; I noticed the SYSTEM.CLUSTER.TRANSMIT.QUEUE is a FIFO queue by default.
I have just observed this phenomenon in our environment, where a cluster queue manager was down and so channels to it were in RETRY. There were messages destined to the SYSTEM.CLUSTER.COMMAND.QUEUE of this downed queue manager, but these messages were sitting on the SYSTEM.CLUSTER.TRANSMIT.QUEUE of the full repository queue managers, potential causing a problem with the delivery of messages to other queue managers.
Is anyone familiar with this "problem"?
Thankx |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Apr 05, 2007 6:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Did you demonstrate, while there were messages on that queue, that other messages were not delivered?
Or are you just guessing that Clustering would be implemented like that? It would seem a bad design to me. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
hilltops |
Posted: Thu Apr 05, 2007 6:43 am Post subject: |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
No, I have not demonstrated that messages are not being delivered, but was concerned that they might not be. That's why I said "problem" ( in quotes). My question was more of an attempt to understand the clustering delievery mechanism in such circumstances. |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Apr 05, 2007 6:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
The availability of one queue manager will not affect the delivery of messages to any other queue manager, except for messages FROM the unavailable qmgr. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
hilltops |
Posted: Thu Apr 05, 2007 7:03 am Post subject: |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
No imagine the following scenario. all the following are in the same cluster, say CLUSA.
A message flow is designed to flow over three queue managers;
QM_A -> QM_B - QM_C. QM_B is the repository.
The queue definitions is as follows;
Qalias on QM_A which targets qalias on QM_B which targets qlocal on QM_C.
There's another queue manager in the cluster, QM_D, but it is down. Command messages destined for QM_D are in the cluster transmit queue on QM_B, and cannot be delivered until QM_D is brought back up.
My question is; How do messages targeting QM_C get to their destination? Are they not put in the cluster transmit queue on QM_B for subsequent transmission to QM_C? |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Apr 05, 2007 7:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Imagine that the developers of the product considered that scenario, and designed and coded it properly, such that
Quote: |
The availability of one queue manager will not affect the delivery of messages to any other queue manager, except for messages FROM the unavailable qmgr. |
_________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
EddieA |
Posted: Thu Apr 05, 2007 11:13 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
hilltops wrote: |
Qalias on QM_A which targets qalias on QM_B which targets qlocal on QM_C. |
Why are you doing this if the QMs are clustered. The application on QM_A names a Queue on QM_C, and MQ does the rest.
hilltops wrote: |
My question is; How do messages targeting QM_C get to their destination? Are they not put in the cluster transmit queue on QM_B for subsequent transmission to QM_C? |
In your scenarion, yes, and then they are delivered immediately, if the channel between QM_B and QM_C is available.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
hilltops |
Posted: Thu Apr 05, 2007 3:07 pm Post subject: |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
Thankx EddieA,
I know I can get to QM_C directly without having to go over QM_B, but this is how the system was designed for some historic reasons. So we use QM_B as a central hub over which all messages are routed.
So message delivery from cluster transit queue, which are indeed FIFO queues follows a direct policy than a standard FIFO queue. This is what I suspected, but it is more comforting and more intellectually satisfying to know this than just having to rely on glib quotations from the manual.
Cheers[/quote] |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Apr 05, 2007 3:23 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Clusters try very hard to a) be a fully connected network and b) deliver things in as few hops as possible.
It may be that in your case, the message would actually go directly from QMA to QMC. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Apr 05, 2007 5:12 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
hilltops wrote: |
Thankx EddieA,
I know I can get to QM_C directly without having to go over QM_B, but this is how the system was designed for some historic reasons. So we use QM_B as a central hub over which all messages are routed.
So message delivery from cluster transit queue, which are indeed FIFO queues follows a direct policy than a standard FIFO queue. This is what I suspected, but it is more comforting and more intellectually satisfying to know this than just having to rely on glib quotations from the manual.
Cheers |
[/quote]
Wrong assumption unless you have changed the delivery priority to FIFO. The default on our SYSTEM.CLUSTER.TRANSMIT.QUEUE is PRIORITY...
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
hilltops |
Posted: Fri Apr 06, 2007 1:59 pm Post subject: |
|
|
Centurion
Joined: 01 Mar 2006 Posts: 112
|
Well, I think the issues still remains whether the is is FIFO or PRIORITY. It is clear there is a different mechanism at play for servicing the cluster transmit queue.
Does anyone know whether/where the details of this behaviour is documented. I have not come across it in the cluster manual, unless I have missed something.
Cheers |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Apr 07, 2007 6:04 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
jefflowrey wrote: |
Imagine that the developers of the product considered that scenario, and designed and coded it properly, such that
Quote: |
The availability of one queue manager will not affect the delivery of messages to any other queue manager, except for messages FROM the unavailable qmgr. |
|
And that is all the technical explanation you are likely to get as the details of the process are most probably propriatery to Big Blue...
Why do you need the technical details? Are you planning on changing something from the standard behavior?
Do you need to prove out something?
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
jefflowrey |
Posted: Sat Apr 07, 2007 7:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Nothing I post here is anything other than my own opinion, except where specific documentation is referenced.
I believe there have been some comments here by ivans that may shed some more light. Reading http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzah.doc/csqzah0749.htm
also brings to memory some comments about messages on S.C.T.Q having a special header, in which the CorrelID is used to indicate which qmgr the message belongs to. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Nigelg |
Posted: Mon Apr 09, 2007 11:05 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Jeff is right.
Msgs on the cluster xmitq are read by CorrelId; the CorrelId contains the channel name. This is not secret or proprietary, but does not seem to be as widely known as I thought. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
|