Maybe
rewrite the App so it puts both messages to the same queue as
follows.
Putting App
Msg1
MsgId=None(so new MsgId gets generated) Correlid=0x0102030405 or some other
unique value <- dont use a character string as MsgId's and CorrelId's do
not get translated which can cause platform dependcy issues.
Msg2
MsgId=None CorrelId=Msg1.MsgId
Getting App
Get
Msg1 by using MsgId=None(to select any MsgId) and
CorrelId=0x0102030405
Get
Msg2 by using MsgId=None and CorrelId=Msg1.MsgId
Kind
of a generic solution to different type of messages on the same queue. Also
permits Msg3,4,5 etc. with CorrelId=Msg1.MsgID where Msg1 is a control
message and the number of other messages is unknown till run
time.
Let us
know which route you choose. I'm afraid there's likely to be pain which ever way
you go. Even the above can have problems in that the queue will need to be
indexed to get reasonable performance if there are a large number of messages on
the queue at any one time, which of course has an overhead of its own
:(
Regards
Tim
A
-----Original Message-----
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 5 October 2004 8:09 AM
To: [EMAIL PROTECTED]
Subject: Re: Clustering w/ Message Affinity
I guess that'll work, but it's quite a bit messier than we were hoping for.
"Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>10/04/2004 04:34 PM
MQSeries List <[EMAIL PROTECTED]>
[EMAIL PROTECTED] Re: Clustering w/ Message Affinity
dang, you are right. Forgot about that.
Well, your app will need to maintain a list of available QMs, pick one randomly, and specify the name on the MQOD for the MQOPEN for both queues. You could maintain an MQ Namelist of all these QMs, so the app wouldn't have to change as you add / remove QMs. At least you will get the benefit of reduced Administration for queues and channels.
-----Original Message-----
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, October 04, 2004 5:23 PM
To: [EMAIL PROTECTED]
Subject: Re: Clustering w/ Message Affinity
Can you get a COA if you haven't commited? It seems like there isn't an A to C until after you commit.
"Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>10/04/2004 04:01 PM
MQSeries List <[EMAIL PROTECTED]>
[EMAIL PROTECTED] Re: Clustering w/ Message Affinity
You could MQOPEN Q1, put message1 with a COA, read the COA to see what QM got Message1, and then MQOPEN Q2 specifying the QM where the COA came from, put message2 then commit both and close both queues.
Now both messages will always be on Q1 / Q2 on the same QM. But you will get a random QM each time.
-----Original Message-----
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, October 04, 2004 4:55 PM
To: [EMAIL PROTECTED]
Subject: Clustering w/ Message Affinity
We don't use clustering at our site, but are considering it for a couple of high volume applications. Some of these applications, though, use correlation ID to match messages on two different queues.
To be more specific, a binary message is put to Q1 under syncpoint. A second message is put to Q2. The second message's correlation ID is set to the first message's message ID. Then a commit is done. The getting app gets the message from Q1, and gets the correlated message from Q2 and processes them. This works fine.
But this design requires that both messages have to be delivered to the same target queue manager. How can we guarantee that if we use clustering? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential 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 email and delete this communication and destroy all copies.
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
| This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material. |
