| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| change in reply to queue on the fly? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jeevan |
 Posted: Thu Oct 19, 2006 4:12 am Post subject: change in reply to queue on the fly? |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
A request is made to a cluster queue of which an aaliases is on my client side qmanagers. A reply-to queue is specified in the MQMD header- say LQ1. Lets say a request is sent to the queue to the reply-to queue LQ1 on say qmanager Q1. By some reason the queue manager Q1 goes
down. The message is obviously lost in transmision, but can the app to know failover to using reply-to queue LQ2 on qmanager Q2 for all requests? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Oct 19, 2006 4:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
How does the app know the queue manager Q1 is down & it should use Q2? What's the notification mechanism?
If what you're saying is that the app loses a client connection to Q1 then what you're describing is a client connection table & the app should be coded to reconnect using it.
If what you're saying is that the app is cliented onto a gateway that passes the message to the cluster queue manager Q1, again how does the app know Q1 is non-responsive and Q2 should be used?
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Thu Oct 19, 2006 4:21 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 19, 2006 4:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The basic guiding principles of MQ design and clustering answer your question.
MQ applications should never have any knowledge of the status of the systems they are talking to, more generally never have knowledge of anything about the systems they are talking to.
The message data and the communication pattern (fire&forget, request/reply, pub/sub) are the whole of the contract between two MQ applications.
If a program is bound to a queue manager, and that program sends a request and waits for a reply and THEN the queue manager goes down and can't be reconnected to, the program should expect that it will need to resend the request.
Two instances of an application reading from different instances of a queue in a cluster should be independant of each other. Otherwise, load balancing has no value. This generally means that if one instance sends a request, the other instance can't process the reply. If, for some reason, a particular reply can be processed independantly of who sent the request, then the reply can be load-balanced across the cluster and doesn't need to be sent back to a particular queue manager (so the ReplyToQmgr can be blank).
But the replying program should always use the replytoqmgr and replytq that are set on the request message. If the reply can be load-balanced, then it's the job of the requester to indicate that and not the job of the replier to "guess".
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
