| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Cannot Put To Clustered Queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| Mr Butcher |
 Posted: Tue Aug 02, 2005 5:04 am Post subject: |
 |
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| Do you know if I were to continue to use the redundant aliases in my definitions if it would cause any negative impact? Performance, etc. Aside from just being redundant and goofy? |
it works, but it is confusing (at least to me  )
lets have a look at the name resolution in your case.
your program opens MYAPPLICATION.OUT on APP01
1. the local definitions are checked for a queue named MYAPPLICATION.OUT, and the local defined alias is used.
the resolved targetqueue is QL.MUPRPWEB.OUT
(local queues are checked before cluster queues, as far as i know this will change in the future, or it will be possible to include local queues in the cluster round-robion mechanism. right now (version 5) this is not the case so, if a local queue is found, cluster queues are ignored).
2. the local definitions are checked for QL.MUPRPWEB.OUT, but nothing is found. Because APP01 is member of a cluster, the repository is checked (or the full repository is asked) for instances of QL.MUPRPWEB.OUT, and the proper information is passed from the full repository to APP01.
3. now, APP01 knows about QL.MUPRPWEB.OUT on WEB01 and WEB02, and one of the queues is chosen (if DEFBIND(OPEN), otherwise the target is chosen at put time).
Anyway, the resolved local queue on APP01 (a message can only be put to a local queue) is the SYSTEM.CLUSTER.TRANSMIT.QUEUE wich is the queue that is opened.
what of your definitions is unused? the cluster attribute of the alias defined on APP01 is unused. the alias on WEB01 and WEB02 is unused because the QL.MUPRPWEB.OUT is searched in the cluster.
i wrote before what to change to make things more clear.....
again, it will work the way it is now. if you want to change it, change it on all qmgrs at the same time. (lets assume you change app01 but leave app02 as it is, then app01 will see 3 destinations (because now the alias will be checked in the cluster and there is still an alias on app02 defined).
clustering makes administration easier (less objects needed), but it is strongly recommended to take some time and think about cluster structure and naming conventions and rules what to put into the cluster and what not. this will make life easier once the cluster is running.....
_________________
Regards, Butcher |
|
| Back to top |
|
 |
| sysera |
| Posted: Tue Aug 02, 2005 5:12 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
One thing I find interesting is that if I remove all of the unecessary aliases from the queue managers and I put:
from app01
1
2
3
4
5
from app02
6
7
8
9
10
Almost all ten messages end up on a single web server, instead of 5 and 5. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Aug 02, 2005 6:09 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
how is the defbind of the qalias on WEB01 and WEB02? from your explaination i assume it is "defbind(open)"
change both queues to defbind(notfixed) and try again
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Aug 02, 2005 6:31 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
one more word to the round robin machanism
this is not a cluster-wide mechanism, every putting queuemanager has its own "counters" (sorry, i do not know how to say better).
app01 does not know which queue is picked by app02, so this information is not involved in the queu selection of app01.
so if you test, put your scope on one queuemanager, lets say app01.
if the queues are defbind(open), and your test is "open, 5 puts, close",
you should see these results when yozu run the test for multiple times
test 1 on app01 -> all 5 messages to web01
test 2 on app01 -> all 5 messages to web02
test 3 on app01 -> all 5 messages to web01
so with defbind open you get a round robin on open basis.
now lets assume the queues are defbind(notfixed)
test 1 on app01 -> msgs 1,3,5 to web01, 2,4 to web02
test 2 on app01 -> msgs 1,3,5 to web02, 2,4 to web01 (hope so)
you get the difference between defbind(open) and defbind(notfixed).
now, if you do parallel testing on app02, this does not affect your testing on app01.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| sysera |
| Posted: Tue Aug 02, 2005 6:56 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
| Mr Butcher wrote: |
one more word to the round robin machanism
this is not a cluster-wide mechanism, every putting queuemanager has its own "counters" (sorry, i do not know how to say better).
app01 does not know which queue is picked by app02, so this information is not involved in the queu selection of app01.
so if you test, put your scope on one queuemanager, lets say app01.
if the queues are defbind(open), and your test is "open, 5 puts, close",
you should see these results when yozu run the test for multiple times
test 1 on app01 -> all 5 messages to web01
test 2 on app01 -> all 5 messages to web02
test 3 on app01 -> all 5 messages to web01
so with defbind open you get a round robin on open basis.
now lets assume the queues are defbind(notfixed)
test 1 on app01 -> msgs 1,3,5 to web01, 2,4 to web02
test 2 on app01 -> msgs 1,3,5 to web02, 2,4 to web01 (hope so)
you get the difference between defbind(open) and defbind(notfixed).
now, if you do parallel testing on app02, this does not affect your testing on app01. |
Ah, I understand. Thank you.  |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
