| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| HELP! - Clustering and Message Affinities |
« View previous topic :: View next topic » |
| Author |
Message
|
| briastep5243 |
 Posted: Mon Dec 09, 2002 1:17 pm Post subject: HELP! - Clustering and Message Affinities |
 |
|
Novice
Joined: 09 Dec 2002
Posts: 11
|
When the queue manager clustering manual talks about message affinities (question/answer type messaging), are they saying that request/reply messages actually have message affinities and that we shouldn't use request/reply messaging in conjuction with a qmgr clustering architecture ???
Or are they referring to a specific type of Request/Reply messages??
See quote from IBM MQ Qmgr Clustering manual:
"Reviewing applications for message affinities:
Before starting to use clusters with multiple definitions of the same queue, examine your applications to see whether there are any that have Message affinities, that is, they exchange related messages. With clusters, a message can be routed to any queue manager that hosts a copy of the correct queue, affecting the logic of applications with message affinities.
Suppose for example, you have two applications that rely on a series of messages flowing between them in the form of questions and answers. It might be important that all the questions are sent to the same queue manager and that all the answers are sent back to the other queue manager. In this situation, it is important that the workload management routine does not send the messages to any queue manager that just happens to host a copy of the correct queue."
Thanks,
B- |
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon Dec 09, 2002 3:44 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
There is nothing wrong with using request/reply in a clustered environment. It may be easiest to explain this with an example. Imagine a large website like yahoo's, where there are hundreds of webservers. When you type www.yahoo.com into your browser, you get directed to one of those webservers. You don't really care which, because the programmers at yahoo made sure that all those webservers give you the same answer. Furthermore, your interaction with yahoo is stateless. That is, while your first page request gets routed to webserver #35, when you type "mqseries" in the search box on their homepage and click "find", the answer to your search request may come from webserver #42, not 35... In other words, there was no affinity between your first request and your second.
Now imagine a second scenario. I walk into a bank and go to one of the tellers and say "I want to make a deposit". They respond with "What is your account number?", and I say, "12345". The teller punches my account number on their screen, and says "How much would you like to deposit?". But now I walk over to a different teller and say, "I want to deposit $200." Well, this second teller doesn't know my account number, and we have to start all over again! In other words, there was an affinity between my first request "my account number is..." and my second request "the amount to deposit is...". The teller's ability to process my second request was dependent on that same teller processing my first request.
If we apply this knowledge to the world of MQ, you'll see why clustering is limited in the second scenario. In the first scenario, clustering works just fine; I can make multiple requests, and I don't care which particular queue manager services them, because they'll all be able to give me the same answer. However, in the second scenario, if my first request is processed by queue manager A, but my second request (which has affinity with the first request) goes to queue manager B, it will be unable to process my second request because it is not the same queue manager that processed my first request.
However, clustering is flexible in that it allows you to define (at MQOPEN time) whether you want all messages your application puts to go to the same instance of a clustered queue (BIND_ON_OPEN) or to be round-robined among all instances of a clustered queue (BIND_NOT_FIXED). If your application has message affinity, you'll need to use BIND_ON_OPEN, otherwise you are free to utilize the round-robin capabilities of clustering.
Hope this clears up your doubts!
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| briastep5243 |
| Posted: Tue Dec 10, 2002 6:45 am Post subject: |
|
|
Novice
Joined: 09 Dec 2002
Posts: 11
|
Brandon,
Thanks for the prompt answer on this.
I suspected that Request/Reply and Question/Answer type messages
were not the same. You confirmed my belief.
Thanks for the thorough explanation!
Much appreciated,
B- |
|
| 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
|
|
|
|
