| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CLUSTER and MQ CLIENT JAVA |
« View previous topic :: View next topic » |
| Author |
Message
|
| kavithadhevi |
 Posted: Tue Jun 11, 2002 9:52 am Post subject: CLUSTER and MQ CLIENT JAVA |
 |
|
Master
Joined: 14 May 2002
Posts: 201
Location: USA
|
Hi,
I am trying to write a java program to connect to the MQ cluster and wanted try out some fail overs.
Can anybody hows experienced in the coding side give me a helping hand to code in java for testing. i am successful in creating cluster QM and Qs in Win 2K MQServer , even adding a remote QM via the MQ explorer. but really i would appreciate how to test for failovers and sample codes to test them esp in JAVA would be greatly appreciated.
_________________
Thanks in Advance. 
Kavitha
IBM Certified System Administrator
Websphere MQ v 5.3
www.zealphoenix.com |
|
| Back to top |
|
 |
| TorpedoSTu |
| Posted: Fri Jun 28, 2002 2:11 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2001
Posts: 73
|
Hiya,
It's pretty simple to test. Howver it must be said that this is only failover of MQ Cluster load balancing and dynamic name resolution within the cluster. It is NOT a replacement for HACMP (on AIX) or similar that gives you fault tolerance capabilities.
Assume the following ....
Two repository qm's on a (remote) machine(s)
One local qm that has joined the cluster.
define the same queue on both repository qm's like ..
def ql(MYQUEUE) defbind(NOTFIXED) cluster(MYCLUS)
Your java program should connect to the local qm and open MYQUEUE (i.e. a remote queue).
Put messages onto MYQUEUE with MQPMO_INPUT_AS_QDEF. This is to pick up hte fact that the bind is not fixed. This is essential to load balancing. If you don't do this then all messages will only go to one of the qm's)
If you put say 10 messages on MYQUEUE, then 5 should be on each of the repository queue managers.
To test failover, simply end one of the repository queue managers whilst your putting to the queue. Messages should then automatically go to the remaining qm. Then re-start the queue manager and messages should then start load balancing again.
You can use the java sample code supplied with mq to build your test harness as all you need to do is connect to a qm and put a message (anything will do).
The next test you might want to try is to delete MYQUEUE from both repositories and add another qm to the cluster, define MYQUEUE here and re-run the test. All messages should end up at MYQUEUE regardless of which repository (or both providing comms exists between the local and remote qm exist, note you don't have to define channels between the local qm and the new remote qm, clustering will auto define htese for you)
Hope this helps
Regs
Stu |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Jun 28, 2002 7:57 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Stu,
You don't specify what bindings to use during the MQPUT. That is why MQPMO_INPUT_AS_QDEF is not the right parameter to use (I don't think that parameter even exists). Bindings occur at the time the queue is opened, so you need to use one of the following open options:
MQOO_BIND_NOT_FIXED
MQOO_BIND_ON_OPEN
MQOO_BIND_AS_Q_DEF
You also mentioned that you can use the java sample code. A lot of people use amqsput to test putting messages to a cluster, and I'd like to mention here again that amqsput is written with MQOO_BIND_ON_OPEN. For this reason, it is useless in regards to testing the workload balancing. I'm not sure about the java sample you're referring to.
And the test you are talking about won't actually work. You say delete MYQUEUE from both repositories, and then define another copy on a third queue manager. This won't work because the moment you delete both instances of MYQUEUE, there won't be any left in the cluster (because you haven't defined the third instance yet) and your MQPUTs will fail. The messages aren't sent to some holding tank, because there is no way of knowing that another instance of MYQUEUE will ever become available. The puts will always fail if there are NO defined instances of a clustered queue. Of course, if instances are defined, but just not accessible, the puts will succeed, but the messages will just stack up on the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| TorpedoSTu |
| Posted: Fri Jun 28, 2002 10:32 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2001
Posts: 73
|
OK take your point about the MQOO options, I got a littel confused there it should have read .....
The MYQUEUE's are defined as DEFBIND(NOTFIXED) and the open should pick this up using MQOO_BIND_AS_Q_DEF
For teh use of the Java sample, the original message asked for a Java test harness, so I said use the Java sample as a basis for the test.
Finally I did say that after deleting the instances of MYQUEUE from the repositories ...
"add another qm to the cluster, define MYQUEUE here and re-run the test"
so I stand by the test as at no time do I say run the test without an instance of the cluster queue MYQUEUE.
Regs
Stuart |
|
| 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
|
|
|
|
