| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Using remote queue application design |
« View previous topic :: View next topic » |
| Author |
Message
|
| sclarke |
 Posted: Thu Jul 29, 2004 4:59 am Post subject: Using remote queue application design |
 |
|
Apprentice
Joined: 05 Jan 2002
Posts: 39
|
Using Remote Queues.
Background:
We are using:
- Mqseries 5.3
- No clustering
- Do not currently have the CAF on the mainframe mq
I am working on the design of a couple of OS/390 applications which will writing messages to a remote queue. These messages will be consumed by a distributed java application. I would like some advice on the best way to code for this…
We would like to be able to have 2 routes to 2 or more different queue managers so that we can take one of the destination queue managers out of service without disrupting the application. This means that I want to know if my put to the first remote queue failed before trying the 2nd.
This is my understanding…
- When you write to a remote queue I will get a 0 return code on the write unless the local remote queue name is incorrect or it is put inhibited. If the remote queue manager is down, the messages will stay in the local xmit queue until the remote queue manager comes back up. If the destination queue on the remote queue manager is full, put inhibited, or invalid name, the message will be put to the remote queue manager’s dead letter queue.
-If I use COA, I will get a confirmation that it was put to the remote queue successfully. But if the message was held up in the send – say the remote queue manager was down and the message spent some time in the xmit queue – I would wait for the reply time out and resend the message down the 2nd route – I would probably have to put an expiry on the message to make sure when the remote queue manager came back up and the messages were sent happily on their way that those messages would expire. But if the reply coa gets held up on the way back to the requesting application and takes longer than the timeout to get back to the requesting application, that application may think that the message didn’t get there (when in fact it did) and try to send down the 2nd path.
Please share any insights or advice!! Thank you very much in advance. |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Jul 29, 2004 5:12 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Having the Java programs "compete" for messages on the mainframe queue using client attach would be the best solution. You need the CAF of course for that to work.
The intent of MQ is to de-couple applications so I would concentrate on making the infrastructure (using hardware clustering etc) reliable, instead of the application trying to compensate for it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 29, 2004 11:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
We would like to be able to have 2 routes to 2 or more different queue managers so that we can take one of the destination queue managers out of service without disrupting the application.
|
This cries for clustering. MQ would take care of routing the messages to only the "live" queues/apps.
Everything else you said is true, as is what zpat said.
| Quote: |
But if the reply coa gets held up on the way back to the requesting application and takes longer than the timeout to get back to the requesting application, that application may think that the message didn’t get there (when in fact it did) and try to send down the 2nd path.
|
If you coded it like this, then you would have to add code that could handle duplicate COAs. And the java app would have to be OK with duplicates as well. If these are Inquiry style messages, then no big deal. But if these are update messages, then I would not go down this dangerous path of sending duplicate messages.
Get clustered or get CAFed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sclarke |
| Posted: Fri Jul 30, 2004 2:26 am Post subject: Using remote queue application design |
|
|
Apprentice
Joined: 05 Jan 2002
Posts: 39
|
Thank you both for your replies - that confirmed my suspicions. As a follow on question... Even if you are in a clustered environment and you have a message that you want to make sure that it got there - like stock trade, time dependent stuff - what are the best practices around this? In theory in a cluster - all routes to the destination could be unavailable or the message gets stuck with others in the cluster xmit queue (if this is still an issue) or the coa doesn't get back in a timely or whatever.
Thanks again! |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jul 30, 2004 4:09 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Don't confuse MQ clusters with hardware clustering MQ queue managers.
With a MQ cluster you can have a message "stuck" if waiting for XMIT when that queue manager goes down.
We use HA/CMP clustering, not MQ clustering. This ensures the queue manager is recovered to the failover node complete with it's data.
No doubt you can combine both methods - but I've never found a good reason to do it.
Make sure your disks are RAID protected on a SAN and then which a hardware server cluster you have no single points of failure. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jul 30, 2004 1:01 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
No doubt you can combine both methods - but I've never found a good reason to do it.
|
We have 2 QMs in an MQ cluster, and the 2 servers they run on are a hardware cluster. When things are happy, the MQ cluster balances the work between both servers, so neither breaks a sweat. If one of the servers has a problem, then the good server suns both QMs, still in an MQ clusters being work load balanced. But now both QMs are competing for resources, so performance may suffer until we restore the environment. Any messages that were persistent and on the QM that failed are not stranded in this design and still get processed when the QM comes up on the backup node.
| Quote: |
Even if you are in a clustered environment and you have a message that you want to make sure that it got there - like stock trade, time dependent stuff - what are the best practices around this?
|
MQ cluster on top of a hardware cluster.
| Quote: |
In theory in a cluster - all routes to the destination could be unavailable
|
Keep adding boxes and $$$ until you feel confident at least one of the routes will be up always.
| Quote: |
or the coa doesn't get back in a timely
|
MQ guarantees THAT the message makes it, not WHEN it makes it. Code your app with this in mind.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
