Using QALIAS to distribute the same message to multiple queues

[Coombs, Lawrence]

I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1

* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace

* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.

* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2

* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

* Now there are two subscriptions to the same topic.

* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.

* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey

Post by Coombs, Lawrence
I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace
2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace
3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace
The destination queues in the subscription definitions are cluster queues that exist on two queue managers.
Test #1
· I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
· I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
· The result was what I expected – 7 messages went to one queue manager while 6 messages went to the other queue manager.
Test #2
· I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
· Now there are two subscriptions to the same topic.
· I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
· The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.
Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.
Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Lawrence,
I think you'll find in a busy MQ cluster the law of large numbers will even things out substantially, but you'll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.



Peter Potkay


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]

[cid:image001.png-***@public.gmane.org]








On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:


I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1
* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2
* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
* Now there are two subscriptions to the same topic.
* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Coombs, Lawrence]

Peter - I don't care about the 50/50 split, even if it is 60/40, or some other ratio, I am fine. The problem is that I cannot have ALL the messages (millions) going to only one queue manager. The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the second subscriber, that's when things don't work the way I expected. Neil's explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
I think you'll find in a busy MQ cluster the law of large numbers will even things out substantially, but you'll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]

[cid:image001.png-***@public.gmane.org]






On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:

I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1
* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2
* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
* Now there are two subscriptions to the same topic.
* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Jefferson Lowrey]

I guess I'm not sure where the issue is.

If you have two subscriptions, you *always* get two copies of *every*
message. That's, um, what a subscription does... give you a new copy of
every message. So when you have two subscriptions, you're getting twice
as many messages. So that's why you have 13 messages going to each qmgr -
because you've produced 26 messages instead of 13.

Typically, you wouldn't use a Topic and a Subscription to handle this.
You'd just let the cluster do the work, and have the sending app use a
QCLUSTER - i.e. remove any manual definitions that define the remote queue
and create two queues that are both shared in the cluster.

If you want to workload balance an application's messages across a
cluster, and the sending application is doing a BIND_ON_OPEN or is
otherwise specifying a fixed qmgr name when it does the put, then you do
have to play a bit crafty with qaliases and etc.

But it's important to remember that a QALIAS only every overrides the
Queue Name, never ever a Queue Manager Name. So you need to use a QREMOTE
instead of a QALIAS to modify what an application sends as the Object
Queue Manager.

Thank you,

Jeff Lowrey



From: "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 10/03/2013 07:58 AM
Subject: Re: [MQSERIES] Using QALIAS to distribute the same message
to multiple queues
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



Peter ? I don?t care about the 50/50 split, even if it is 60/40, or some
other ratio, I am fine. The problem is that I cannot have ALL the
messages (millions) going to only one queue manager. The application does
not want to change to do two sends/puts of the same message, so I thought
that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the
second subscriber, that?s when things don?t work the way I expected.
Neil?s explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple
queues

Lawrence,
I think you?ll find in a busy MQ cluster the law of large numbers will
even things out substantially, but you?ll never be able to guarantee a
pure 50/50 split. Maybe revisit the requirement / desire of having the
messages split 50/50. As long as the messages are being delivered and the
consumers are keeping up it might not really matter if at the end of the
hour/day/week/year one of the queues ended up getting 63.24569% while the
other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple
queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the
standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not
at the queue level. From its perspective, the load balancing is perfect
(13 messages each).

If you look at <
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm

Post by Neil Casey
and check the very last item (point 17) you see that where more than one

instance of a queue is left at the end, the least recently used channel is
chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the
result is deterministic if there is no other traffic. The first instance
of msg1 goes to the first queue manager. The second instance of this
message goes to the second queue manager (and the second queue) because
the channel wins the least recently used test. And so forth, flip flopping
on every message.

If you want to get non-deterministic behaviour, based on each queue or
message rather than the queue manager or channels, then you need to write
your own cluster workload balancing exit. I used to have one for MQ 5.3,
before the supplied algorithm was dramatically enhanced in v6, that used a
simple random number to drive the selection. It worked really well, but
used a lot more CPU than the deterministic algorithm used by IBM (random
number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]








On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <
Lawrence.Coombs-***@public.gmane.org> wrote:

I have a P2P application and now I want the messages to go to two queues.
Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the
TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues
that exist on two queue managers.

Test #1
· I deleted this subscription so that there is only one
destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV')
DEST('NQSX.IAS.INVENTORY.QC02') replace
· I used amqsput to send 13 messages to the qalias
NQSX.IAS.INVENTORY.QA01.
· The result was what I expected ? 7 messages went to one queue
manager while 6 messages went to the other queue manager.

Test #2
· I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
· Now there are two subscriptions to the same topic.
· I used the same amqsput to send 13 messages to the same qalia as
I did in test 1.
· The result was not what I expected. 13 messages went to one
queue manager for the QC01 queue and 13 messages went to the QC02 queue on
the other queue manager.

Is this the way this techniques is supposed to work? I want the messages
to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

"The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem."

You will have the exact same issue if the sending app does two MQPUTs to queues or one MQPUT to a Topic, which in turn causes the Pub Sub Engine to do the two MQPUTs instead of the app. In both cases two messages are leaving the sending QM and the MQ Cluster load balancing quirk Neil mentions interferes with your desired outcome.


Will this cluster only support this one publisher and 2 subscribers? If yes, then I do think the default MQ Cluster load balancing will be problematic for you. But in a busy system with lots of other messages being load balanced at the same time I think you'll get a decent distribution. By lots of other messages I mean in volumes that significantly exceed this one app and to the same queue managers. The same queue managers point is important. We ran into this several years ago when App1 only had clustered queues on QM1 and QM2, while App 2 had clustered queues on QM1, QM2, QM3, QM4. All were in the same cluster. It took a while to figure out why the majority of App 2's messages went to QM3 and QM4 instead of 25/25/25/25%. It was App1's load interfering with App 2's distribution. App1 was causing the channels to QM1 and QM2 to be more heavily used.


"The problem is that I cannot have ALL the messages (millions) going to only one queue manager."
Is this because the consumer(s) on that one queue could not keep up with the arrival rate? But if some of the messages were load balanced to the other instance of the queue in the cluster they could?


Peter Potkay


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Coombs, Lawrence
Sent: Thursday, October 03, 2013 7:57 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Peter - I don't care about the 50/50 split, even if it is 60/40, or some other ratio, I am fine. The problem is that I cannot have ALL the messages (millions) going to only one queue manager. The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the second subscriber, that's when things don't work the way I expected. Neil's explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
I think you'll find in a busy MQ cluster the law of large numbers will even things out substantially, but you'll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]

[cid:image001.png-+3OrjZzCWyReoZJKZ+***@public.gmane.org]




On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:

I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1
* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2
* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
* Now there are two subscriptions to the same topic.
* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Coombs, Lawrence]

Now I am even more confused.

I ran a couple more tests.

Test #1

* I deleted the second subscription for the QC02 queue.

* Ran amqsput to send 13 messages.

* 7 went to one queue manager and 6 went to the other (QC01 instance)


Test #2


* I created a second alias with a different topic

def qalias('NQSX.IAS.INVENTORY.QA02') +
TARGET('NQSXRTIINV1') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace


* I created a new topic

def TOPIC('NQSXRTIINV1') +
TOPICSTR('NQSXRTIINV1') replace


* I created a new subscription
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV1') +
DEST('NQSX.IAS.INVENTORY.QC02') replace


* With the channels to both of the receiving queue managers running, I then reran the amqsput sending to the QA02 alias and the messages were distributed
7 to one queue manager and 6 to the other queue manager for the QC02 queue.

Neil, this blows your theory.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 7:20 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues

"The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem."

You will have the exact same issue if the sending app does two MQPUTs to queues or one MQPUT to a Topic, which in turn causes the Pub Sub Engine to do the two MQPUTs instead of the app. In both cases two messages are leaving the sending QM and the MQ Cluster load balancing quirk Neil mentions interferes with your desired outcome.


Will this cluster only support this one publisher and 2 subscribers? If yes, then I do think the default MQ Cluster load balancing will be problematic for you. But in a busy system with lots of other messages being load balanced at the same time I think you'll get a decent distribution. By lots of other messages I mean in volumes that significantly exceed this one app and to the same queue managers. The same queue managers point is important. We ran into this several years ago when App1 only had clustered queues on QM1 and QM2, while App 2 had clustered queues on QM1, QM2, QM3, QM4. All were in the same cluster. It took a while to figure out why the majority of App 2's messages went to QM3 and QM4 instead of 25/25/25/25%. It was App1's load interfering with App 2's distribution. App1 was causing the channels to QM1 and QM2 to be more heavily used.


"The problem is that I cannot have ALL the messages (millions) going to only one queue manager."
Is this because the consumer(s) on that one queue could not keep up with the arrival rate? But if some of the messages were load balanced to the other instance of the queue in the cluster they could?


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Coombs, Lawrence
Sent: Thursday, October 03, 2013 7:57 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Peter - I don't care about the 50/50 split, even if it is 60/40, or some other ratio, I am fine. The problem is that I cannot have ALL the messages (millions) going to only one queue manager. The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the second subscriber, that's when things don't work the way I expected. Neil's explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
I think you'll find in a busy MQ cluster the law of large numbers will even things out substantially, but you'll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]

[cid:image001.png-***@public.gmane.org]




On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:

I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1
* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2
* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
* Now there are two subscriptions to the same topic.
* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Coombs, Lawrence]

"The problem is that I cannot have ALL the messages (millions) going to only one queue manager."
Is this because the consumer(s) on that one queue could not keep up with the arrival rate? But if some of the messages were load balanced to the other instance of the queue in the cluster they could?

The answer is yes. The consumers on one queue manager could not keep up with the volume of messages that it would be generating.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 7:20 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues

"The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem."

You will have the exact same issue if the sending app does two MQPUTs to queues or one MQPUT to a Topic, which in turn causes the Pub Sub Engine to do the two MQPUTs instead of the app. In both cases two messages are leaving the sending QM and the MQ Cluster load balancing quirk Neil mentions interferes with your desired outcome.


Will this cluster only support this one publisher and 2 subscribers? If yes, then I do think the default MQ Cluster load balancing will be problematic for you. But in a busy system with lots of other messages being load balanced at the same time I think you'll get a decent distribution. By lots of other messages I mean in volumes that significantly exceed this one app and to the same queue managers. The same queue managers point is important. We ran into this several years ago when App1 only had clustered queues on QM1 and QM2, while App 2 had clustered queues on QM1, QM2, QM3, QM4. All were in the same cluster. It took a while to figure out why the majority of App 2's messages went to QM3 and QM4 instead of 25/25/25/25%. It was App1's load interfering with App 2's distribution. App1 was causing the channels to QM1 and QM2 to be more heavily used.


"The problem is that I cannot have ALL the messages (millions) going to only one queue manager."
Is this because the consumer(s) on that one queue could not keep up with the arrival rate? But if some of the messages were load balanced to the other instance of the queue in the cluster they could?


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Coombs, Lawrence
Sent: Thursday, October 03, 2013 7:57 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Peter - I don't care about the 50/50 split, even if it is 60/40, or some other ratio, I am fine. The problem is that I cannot have ALL the messages (millions) going to only one queue manager. The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the second subscriber, that's when things don't work the way I expected. Neil's explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
I think you'll find in a busy MQ cluster the law of large numbers will even things out substantially, but you'll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]

[cid:image001.png-***@public.gmane.org]




On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:

I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1
* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2
* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
* Now there are two subscriptions to the same topic.
* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Michael Dag]

Lawrence,

Not the prettiest solution, but you could 'move' the pub/sub to the cluster
destination queuemanagers (now it's on the sending queuemanager),

So replace the current destination queues by clustered aliases and point
these aliases to local topics and hang the subscriptions off those on each
destination queuemanager.

It's more work, but also makes sure the 1 msg is replicated into 2 msgs on
the same destination queuemanager



Hope this helps!



Michael



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Coombs, Lawrence
Sent: donderdag 3 oktober 2013 13:57
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues



Peter - I don't care about the 50/50 split, even if it is 60/40, or some
other ratio, I am fine. The problem is that I cannot have ALL the messages
(millions) going to only one queue manager. The application does not want to
change to do two sends/puts of the same message, so I thought that using
this qalias technique would solve the problem.



It works when there is only one subscriber to the topic. When I add the
second subscriber, that's when things don't work the way I expected. Neil's
explained what might be going on under the covers.



I will have to find another way.



Thanks for the response.



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues



Lawrence,

I think you'll find in a busy MQ cluster the law of large numbers will even
things out substantially, but you'll never be able to guarantee a pure 50/50
split. Maybe revisit the requirement / desire of having the messages split
50/50. As long as the messages are being delivered and the consumers are
keeping up it might not really matter if at the end of the
hour/day/week/year one of the queues ended up getting 63.24569% while the
other got the remainder.







Peter Potkay



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues



Hi Lawrence,



I believe that you have been caught by one of the strangenesses in the
standard cluster workload balancing algorithm.



It is designed to load balance at the queue manager or channel level, not at
the queue level. From its perspective, the load balancing is perfect (13
messages each).



If you look at
<http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q
082390_.htm> and check the very last item (point 17) you see that where more
than one instance of a queue is left at the end, the least recently used
channel is chosen.



If you have pub/sub, 2 queues, and 2 destination queue managers, the result
is deterministic if there is no other traffic. The first instance of msg1
goes to the first queue manager. The second instance of this message goes to
the second queue manager (and the second queue) because the channel wins the
least recently used test. And so forth, flip flopping on every message.



If you want to get non-deterministic behaviour, based on each queue or
message rather than the queue manager or channels, then you need to write
your own cluster workload balancing exit. I used to have one for MQ 5.3,
before the supplied algorithm was dramatically enhanced in v6, that used a
simple random number to drive the selection. It worked really well, but used
a lot more CPU than the deterministic algorithm used by IBM (random number
generation is expensive in CPU terms).



Regards,





Neil Casey

mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]














On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org>
wrote:



I have a P2P application and now I want the messages to go to two queues.
Therefore, I created an alias, a topic and two subscriptions.

Here are the object definitions:



1. Define an alias queue of type TOPIC.

def qalias('NQSX.IAS.INVENTORY.QA01') +

TARGET('NQSXRTIINV') +

DEFBIND(NOTFIXED) +

TARGTYPE(TOPIC) replace



2. Next define a topic for each ALIAS with the same name as the
TARGET

def TOPIC('NQSXRTIINV') +

TOPICSTR('NQSXRTIINV') replace



3. Define a subscription for each recipient

def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +

DEST('NQSX.IAS.INVENTORY.QC02') replace



def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +

DEST('NQSX.IAS.INVENTORY.QC01') replace



The destination queues in the subscription definitions are cluster queues
that exist on two queue managers.



Test #1

. I deleted this subscription so that there is only one destination
receiving messages ('NQSX.IAS.INVENTORY.QC01')

def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV')
DEST('NQSX.IAS.INVENTORY.QC02') replace

. I used amqsput to send 13 messages to the qalias
NQSX.IAS.INVENTORY.QA01.

. The result was what I expected - 7 messages went to one queue
manager while 6 messages went to the other queue manager.



Test #2

. I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +

DEST('NQSX.IAS.INVENTORY.QC02') replace

. Now there are two subscriptions to the same topic.

. I used the same amqsput to send 13 messages to the same qalia as I
did in test 1.

. The result was not what I expected. 13 messages went to one queue
manager for the QC01 queue and 13 messages went to the QC02 queue on the
other queue manager.



Is this the way this techniques is supposed to work? I want the messages to
be distributed almost equally on both queue managers for both queues.



Note: The cluster queues are defined with DEFBIND(NOTFIXED).

This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.



_____

<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com





_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************



_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.



_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>

Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi Lawrence,

I don't understand why you think this is unexpected. It looks to me like you sent 13 messages to a topic with only 1 subscriber, and 13 messages showed up, load balanced between 2 queue managers. This is what I would expect.

If you create 2 subscriptions, to 2 queues, each of which exist on both target queue managers, the problem should come back. The problem is that the load balancing algorithm operates effectively at the queue manager (actually channel) level, not for each queue.

As Peter said, if this is happening on a queue manager with lots of other traffic as well, it shouldn't matter too much.

But if you really need things load balanced more evenly, at a queue level rather than queue manager, you are going to have to write your own CLWLEXIT.

Regards,

Neil Casey

Post by Coombs, Lawrence
Now I am even more confused.
I ran a couple more tests.
Test #1
· I deleted the second subscription for the QC02 queue.
· Ran amqsput to send 13 messages.
· 7 went to one queue manager and 6 went to the other (QC01 instance)
Test #2
· I created a second alias with a different topic
def qalias('NQSX.IAS.INVENTORY.QA02') +
TARGET('NQSXRTIINV1') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace
· I created a new topic
def TOPIC('NQSXRTIINV1') +
TOPICSTR('NQSXRTIINV1') replace
· I created a new subscription
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV1') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
· With the channels to both of the receiving queue managers running, I then reran the amqsput sending to the QA02 alias and the messages were distributed
7 to one queue manager and 6 to the other queue manager for the QC02 queue.
Neil, this blows your theory.
Sent: Thursday, October 03, 2013 7:20 AM
Subject: Re: Using QALIAS to distribute the same message to multiple queues
“The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.”
You will have the exact same issue if the sending app does two MQPUTs to queues or one MQPUT to a Topic, which in turn causes the Pub Sub Engine to do the two MQPUTs instead of the app. In both cases two messages are leaving the sending QM and the MQ Cluster load balancing quirk Neil mentions interferes with your desired outcome.
Will this cluster only support this one publisher and 2 subscribers? If yes, then I do think the default MQ Cluster load balancing will be problematic for you. But in a busy system with lots of other messages being load balanced at the same time I think you’ll get a decent distribution. By lots of other messages I mean in volumes that significantly exceed this one app and to the same queue managers. The same queue managers point is important. We ran into this several years ago when App1 only had clustered queues on QM1 and QM2, while App 2 had clustered queues on QM1, QM2, QM3, QM4. All were in the same cluster. It took a while to figure out why the majority of App 2’s messages went to QM3 and QM4 instead of 25/25/25/25%. It was App1’s load interfering with App 2’s distribution. App1 was causing the channels to QM1 and QM2 to be more heavily used.
“The problem is that I cannot have ALL the messages (millions) going to only one queue manager.”
Is this because the consumer(s) on that one queue could not keep up with the arrival rate? But if some of the messages were load balanced to the other instance of the queue in the cluster they could?
Peter Potkay
Sent: Thursday, October 03, 2013 7:57 AM
Subject: Re: Using QALIAS to distribute the same message to multiple queues
Peter – I don’t care about the 50/50 split, even if it is 60/40, or some other ratio, I am fine. The problem is that I cannot have ALL the messages (millions) going to only one queue manager. The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.
It works when there is only one subscriber to the topic. When I add the second subscriber, that’s when things don’t work the way I expected. Neil’s explained what might be going on under the covers.
I will have to find another way.
Thanks for the response.
Sent: Thursday, October 03, 2013 6:51 AM
Subject: Re: Using QALIAS to distribute the same message to multiple queues
Lawrence,
I think you’ll find in a busy MQ cluster the law of large numbers will even things out substantially, but you’ll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.
Peter Potkay
Sent: Thursday, October 03, 2013 1:47 AM
Subject: Re: Using QALIAS to distribute the same message to multiple queues
Hi Lawrence,
I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.
It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).
If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.
If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.
If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).
Regards,
Neil Casey
<image001.png>
I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace
2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace
3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace
The destination queues in the subscription definitions are cluster queues that exist on two queue managers.
Test #1
· I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
· I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
· The result was what I expected – 7 messages went to one queue manager while 6 messages went to the other queue manager.
Test #2
· I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
· Now there are two subscriptions to the same topic.
· I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
· The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.
Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.
Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Coombs, Lawrence]

I will test it out and let you know.
Thanks for the suggestion.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Michael Dag
Sent: Thursday, October 03, 2013 8:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
Not the prettiest solution, but you could 'move' the pub/sub to the cluster destination queuemanagers (now it's on the sending queuemanager),
So replace the current destination queues by clustered aliases and point these aliases to local topics and hang the subscriptions off those on each destination queuemanager.
It's more work, but also makes sure the 1 msg is replicated into 2 msgs on the same destination queuemanager

Hope this helps!

Michael

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Coombs, Lawrence
Sent: donderdag 3 oktober 2013 13:57
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Peter - I don't care about the 50/50 split, even if it is 60/40, or some other ratio, I am fine. The problem is that I cannot have ALL the messages (millions) going to only one queue manager. The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the second subscriber, that's when things don't work the way I expected. Neil's explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
I think you'll find in a busy MQ cluster the law of large numbers will even things out substantially, but you'll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]

[cid:image001.png-***@public.gmane.org]




On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:

I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1
* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2
* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
* Now there are two subscriptions to the same topic.
* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Jefferson Lowrey]

I'm still not sure what the real goal here is.

Assume the sending application creates 13 messages.

Is the goal to have only those 13 messages received by consuming
applications - with some of those 13 sent to one queue manager, and some
of those 13 sent to another queue manager?

This is just plain clustering. No pub/sub needed.

Is the goal to have 26 messages (2 copies of each message sent) received
by consuming applications? With some of those 26 sent to one queue
manager and some of those 26 sent to another?

Then that's what Lawrence achieved with his two subscriptions. Those 26
messages were load balanced across the cluster.

Is the goal to have x% (for some value of x) of messages received by one
queue manager and 100-x% received by another? There are tuning parameters
on cluster channels to help this.

Michael - your workaround is good, but if one is not careful with the
placement, sharing, and configuration of the cluster , the subscriptions,
and the aliases then it could end up creating 52 messages instead of 26.

Mixing pub/sub and clustering requires careful consideration and planning.



Thank you,

Jeff Lowrey



From: Michael Dag <maillists-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 10/03/2013 09:33 AM
Subject: Re: [MQSERIES] Using QALIAS to distribute the same message
to multiple queues
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>



Lawrence,
Not the prettiest solution, but you could ?move? the pub/sub to the
cluster destination queuemanagers (now it?s on the sending queuemanager),
So replace the current destination queues by clustered aliases and point
these aliases to local topics and hang the subscriptions off those on each
destination queuemanager.
It?s more work, but also makes sure the 1 msg is replicated into 2 msgs on
the same destination queuemanager

Hope this helps!

Michael

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Coombs, Lawrence
Sent: donderdag 3 oktober 2013 13:57
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple
queues

Peter ? I don?t care about the 50/50 split, even if it is 60/40, or some
other ratio, I am fine. The problem is that I cannot have ALL the
messages (millions) going to only one queue manager. The application does
not want to change to do two sends/puts of the same message, so I thought
that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the
second subscriber, that?s when things don?t work the way I expected.
Neil?s explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple
queues

Lawrence,
I think you?ll find in a busy MQ cluster the law of large numbers will
even things out substantially, but you?ll never be able to guarantee a
pure 50/50 split. Maybe revisit the requirement / desire of having the
messages split 50/50. As long as the messages are being delivered and the
consumers are keeping up it might not really matter if at the end of the
hour/day/week/year one of the queues ended up getting 63.24569% while the
other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf
Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple
queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the
standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not
at the queue level. From its perspective, the load balancing is perfect
(13 messages each).

If you look at <
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm

Post by Neil Casey
and check the very last item (point 17) you see that where more than one

instance of a queue is left at the end, the least recently used channel is
chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the
result is deterministic if there is no other traffic. The first instance
of msg1 goes to the first queue manager. The second instance of this
message goes to the second queue manager (and the second queue) because
the channel wins the least recently used test. And so forth, flip flopping
on every message.

If you want to get non-deterministic behaviour, based on each queue or
message rather than the queue manager or channels, then you need to write
your own cluster workload balancing exit. I used to have one for MQ 5.3,
before the supplied algorithm was dramatically enhanced in v6, that used a
simple random number to drive the selection. It worked really well, but
used a lot more CPU than the deterministic algorithm used by IBM (random
number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]






On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <
Lawrence.Coombs-***@public.gmane.org> wrote:

I have a P2P application and now I want the messages to go to two queues.
Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the
TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues
that exist on two queue managers.

Test #1
· I deleted this subscription so that there is only one
destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV')
DEST('NQSX.IAS.INVENTORY.QC02') replace
· I used amqsput to send 13 messages to the qalias
NQSX.IAS.INVENTORY.QA01.
· The result was what I expected ? 7 messages went to one queue
manager while 6 messages went to the other queue manager.

Test #2
· I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
· Now there are two subscriptions to the same topic.
· I used the same amqsput to send 13 messages to the same qalia as
I did in test 1.
· The result was not what I expected. 13 messages went to one
queue manager for the QC01 queue and 13 messages went to the QC02 queue on
the other queue manager.

Is this the way this techniques is supposed to work? I want the messages
to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com



List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
This message, including any attachments, is the property of Sears Holdings
Corporation and/or one of its subsidiaries. It is confidential and may
contain proprietary or legally privileged information. If you are not the
intended recipient, please delete it without reading the contents. Thank
you.


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Bruce Lerner]

“The problem is that I cannot have ALL the messages (millions) going to only
one queue manager.”

Do you really mean that the requirement specifies that under absolutely NO
circumstances whatsoever ALL messages go to one queue-manager?

I'm thinking of the situation where the 2nd queue-manager is down or under
severe stress? If 60/40 is ok, what about 70/30? 80/20? 90/10?

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Potkay, Peter M (CTO Architecture + Engineering)]

"It's more work, but also makes sure the 1 msg is replicated into 2 msgs on the same destination queuemanager"

But subsequent messages published will still be vulnerable to be predominantly and maybe even exclusively load 'balanced' to one destination queue manager. Unfortunately I don't think this helps circumvent Mr.Coombs dilemma.




Peter Potkay


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Michael Dag
Sent: Thursday, October 03, 2013 9:02 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
Not the prettiest solution, but you could 'move' the pub/sub to the cluster destination queuemanagers (now it's on the sending queuemanager),
So replace the current destination queues by clustered aliases and point these aliases to local topics and hang the subscriptions off those on each destination queuemanager.
It's more work, but also makes sure the 1 msg is replicated into 2 msgs on the same destination queuemanager

Hope this helps!

Michael

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Coombs, Lawrence
Sent: donderdag 3 oktober 2013 13:57
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Peter - I don't care about the 50/50 split, even if it is 60/40, or some other ratio, I am fine. The problem is that I cannot have ALL the messages (millions) going to only one queue manager. The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the second subscriber, that's when things don't work the way I expected. Neil's explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
I think you'll find in a busy MQ cluster the law of large numbers will even things out substantially, but you'll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]

[cid:image001.png-MCemkr2WAxyGZ/***@public.gmane.org]




On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:

I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1
* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2
* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
* Now there are two subscriptions to the same topic.
* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

What about modifying AMQSCLM to not only check IPROCS but to also consider number of message enqueued. If the difference between your clustered queues crosses your threshold the program could adjust CLWLPRTY for new messages to help get things balanced again.

Eh, seems like this is more complicated than it needs to be. Why doesn't MQ just load balance evenly at the queue level. I suppose some people may want their channel traffic between QMs to be evenly balanced. Maybe that was the primary concerns in years past with slower servers and slower networks. I think nowadays most everybody would want queue level load balancing be default.





Peter Potkay


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Thursday, October 03, 2013 9:46 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Using QALIAS to distribute the same message to multiple queues

I'm still not sure what the real goal here is.

Assume the sending application creates 13 messages.

Is the goal to have only those 13 messages received by consuming applications - with some of those 13 sent to one queue manager, and some of those 13 sent to another queue manager?

This is just plain clustering. No pub/sub needed.

Is the goal to have 26 messages (2 copies of each message sent) received by consuming applications? With some of those 26 sent to one queue manager and some of those 26 sent to another?

Then that's what Lawrence achieved with his two subscriptions. Those 26 messages were load balanced across the cluster.

Is the goal to have x% (for some value of x) of messages received by one queue manager and 100-x% received by another? There are tuning parameters on cluster channels to help this.

Michael - your workaround is good, but if one is not careful with the placement, sharing, and configuration of the cluster , the subscriptions, and the aliases then it could end up creating 52 messages instead of 26.

Mixing pub/sub and clustering requires careful consideration and planning.


Thank you,

Jeff Lowrey



From: Michael Dag <maillists-***@public.gmane.org<mailto:***@MQSYSTEMS.COM>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>,
Date: 10/03/2013 09:33 AM
Subject: Re: [MQSERIES] Using QALIAS to distribute the same message to multiple queues
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________



Lawrence,
Not the prettiest solution, but you could 'move' the pub/sub to the cluster destination queuemanagers (now it's on the sending queuemanager),
So replace the current destination queues by clustered aliases and point these aliases to local topics and hang the subscriptions off those on each destination queuemanager.
It's more work, but also makes sure the 1 msg is replicated into 2 msgs on the same destination queuemanager

Hope this helps!

Michael

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Coombs, Lawrence
Sent: donderdag 3 oktober 2013 13:57
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Peter - I don't care about the 50/50 split, even if it is 60/40, or some other ratio, I am fine. The problem is that I cannot have ALL the messages (millions) going to only one queue manager. The application does not want to change to do two sends/puts of the same message, so I thought that using this qalias technique would solve the problem.

It works when there is only one subscriber to the topic. When I add the second subscriber, that's when things don't work the way I expected. Neil's explained what might be going on under the covers.

I will have to find another way.

Thanks for the response.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, October 03, 2013 6:51 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Lawrence,
I think you'll find in a busy MQ cluster the law of large numbers will even things out substantially, but you'll never be able to guarantee a pure 50/50 split. Maybe revisit the requirement / desire of having the messages split 50/50. As long as the messages are being delivered and the consumers are keeping up it might not really matter if at the end of the hour/day/week/year one of the queues ended up getting 63.24569% while the other got the remainder.



Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, October 03, 2013 1:47 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Using QALIAS to distribute the same message to multiple queues

Hi Lawrence,

I believe that you have been caught by one of the strangenesses in the standard cluster workload balancing algorithm.

It is designed to load balance at the queue manager or channel level, not at the queue level. From its perspective, the load balancing is perfect (13 messages each).

If you look at <http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.con.doc/q082390_.htm> and check the very last item (point 17) you see that where more than one instance of a queue is left at the end, the least recently used channel is chosen.

If you have pub/sub, 2 queues, and 2 destination queue managers, the result is deterministic if there is no other traffic. The first instance of msg1 goes to the first queue manager. The second instance of this message goes to the second queue manager (and the second queue) because the channel wins the least recently used test. And so forth, flip flopping on every message.

If you want to get non-deterministic behaviour, based on each queue or message rather than the queue manager or channels, then you need to write your own cluster workload balancing exit. I used to have one for MQ 5.3, before the supplied algorithm was dramatically enhanced in v6, that used a simple random number to drive the selection. It worked really well, but used a lot more CPU than the deterministic algorithm used by IBM (random number generation is expensive in CPU terms).

Regards,


Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: [phone]

[cid:image001.png-***@public.gmane.org]





On 03/10/2013, at 12:16 PM, "Coombs, Lawrence" <Lawrence.Coombs-***@public.gmane.org<mailto:Lawrence.Coombs-***@public.gmane.org>> wrote:

I have a P2P application and now I want the messages to go to two queues. Therefore, I created an alias, a topic and two subscriptions.
Here are the object definitions:

1. Define an alias queue of type TOPIC.
def qalias('NQSX.IAS.INVENTORY.QA01') +
TARGET('NQSXRTIINV') +
DEFBIND(NOTFIXED) +
TARGTYPE(TOPIC) replace

2. Next define a topic for each ALIAS with the same name as the TARGET
def TOPIC('NQSXRTIINV') +
TOPICSTR('NQSXRTIINV') replace

3. Define a subscription for each recipient
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace

def SUB(NQSXRTIINV2) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC01') replace

The destination queues in the subscription definitions are cluster queues that exist on two queue managers.

Test #1
* I deleted this subscription so that there is only one destination receiving messages ('NQSX.IAS.INVENTORY.QC01')
def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') DEST('NQSX.IAS.INVENTORY.QC02') replace
* I used amqsput to send 13 messages to the qalias NQSX.IAS.INVENTORY.QA01.
* The result was what I expected - 7 messages went to one queue manager while 6 messages went to the other queue manager.

Test #2
* I re-defined the def SUB(NQSXRTIINV1) TOPICSTR('NQSXRTIINV') +
DEST('NQSX.IAS.INVENTORY.QC02') replace
* Now there are two subscriptions to the same topic.
* I used the same amqsput to send 13 messages to the same qalia as I did in test 1.
* The result was not what I expected. 13 messages went to one queue manager for the QC01 queue and 13 messages went to the QC02 queue on the other queue manager.

Is this the way this techniques is supposed to work? I want the messages to be distributed almost equally on both queue managers for both queues.

Note: The cluster queues are defined with DEFBIND(NOTFIXED).
This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

________________________________

List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>



________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Bruce Lerner]

I'm going to take a guess here that neither server hardware platform is
sufficiently provisioned to take on the entire workload, and thus the
requirement to split the workload between the two servers. I suppose this
makes sense... until one or the other server becomes unavailable for any
reason.

I've tried, with some success, to explain to managers that two servers
similarly configured (100% each) does NOT = 200% processing capacity.

A similar argument: Two VW bugs can carry 8 people from point A to point B.
No, it's 4 each. If one VW gets a flat, or runs out of gas...

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES