| Author |
Message
|
| Brody2 |
 Posted: Wed Dec 28, 2005 12:27 pm Post subject: Does clustering work with Smalltalk? |
 |
|
Newbie
Joined: 28 Dec 2005
Posts: 2
|
Trying to get clustering to work with Smalltalk (VA_6.01). I can read from a cluster, but can't seem to write to one.
Keep getting Uknown Object Name, Invalid Handle on open, etc. (Depends on what I'm screwing around with?.  )
Anyhow, any advice, info would be appreciated.
Brody2 |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Dec 28, 2005 12:30 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You sure you don't have it backwards - that you can write to a cluster, but not read from one? It's a fairly common misunderstanding when things happen like that.
If you can execute any kind of Put to a queue manager at all, then you should have no trouble putting to a qcluster.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Brody2 |
| Posted: Wed Dec 28, 2005 12:41 pm Post subject: |
|
|
Newbie
Joined: 28 Dec 2005
Posts: 2
|
| Quote: |
| You sure you don't have it backwards |
Nope, this is what's happening.
The mainframe writes messages to the cluster, which we can retrieve.
We then process the message, and try to PUT them back to a "DIFFERENT" queue on the cluster, and get the failures.
i.e.: mainframe writes to RQST.ONL.
smalltalk code gets message.
smalltalk code massages message and builds reply.
smalltalk code QPUT1 to RPLY20.ONL and gets failure during open.
However, I am an MQ newbie, so will appreciate any pointers/hints/ etc, since most of the time I do have NO IDEA what I'm talking about.
Thanks,
Brody2 |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Dec 28, 2005 1:31 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Keep getting Uknown Object Name |
You are probably specifying both a Queue and a Queue manager. For a Cluster, you should only use Queue and let MQ work out the QM part.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 28, 2005 1:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Easiest solution would be to use a cluster alias which is resolved in each qmgr in the cluster. Thus you would always use a qmgr in your reply to info. However not all reply queues need to be members of the cluster Should that be the case you need to define a default way for the cluster to find its way to the target/requesting qmgr (aliasing etc...)
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 28, 2005 5:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
Easiest solution would be to use a cluster alias which is resolved in each qmgr in the cluster. Thus you would always use a qmgr in your reply to info. However not all reply queues need to be members of the cluster Should that be the case you need to define a default way for the cluster to find its way to the target/requesting qmgr (aliasing etc...)
Enjoy |
They are not needed fjb.
If QueueA is on QM1, and QM1 is in the cluster, and QueueA is NOT clustered, an app connected to any other QM in the cluster can get a message to QueueA by insuring they specify QueueA and QM1 together on the MQOPEN call. MQ clustering automagically gets the mesage there.
But I agree the original problem is most likely the app is connected to QMxyz, the destination queue (Queue123) is hosted on other QM(s) in the cluster, but on the MQOPEN call, he is specifying Queue123 and QMxyz, and QMxyz is correctly yakking and saying I have no such queue. Eddie's solution is correct, assuming Queue123 is clustered and he doesn't care which instance of it his message goes to. (If this indeed is the error.) Brody, in the future, MQ error codes help us help you.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 28, 2005 7:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The advantage with my solution is that it covers all 3 bases:
a) the queue is clustered but not on processing qmgr
The cluster alias will take care of it.
b) the queue is not clustered but on one of the qmgrs in the cluster
not a problem as a default way to the qmgrs in the cluster exists
c) the queue is not clustered and on a qmgr outside of the cluster
A default way to the qmgr must be made known to the cluster or at least to the processing manager.
In no case is the qmgr field from the reply to information left blank. This takes care of the odd cases (JMS) where this is defaulted to the current qmgr if left blank.
Enjoy |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 29, 2005 6:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
For situation C, yes, you do need a QM Alias on the gateway advertising every QM that is outside of the cluster, no way around that.
But for A and B, you just do not need QM aliases for QMs in the cluster defined anywhere in the cluster. And even if you did have them, they wont help in the cases where the app specifys the local QM on on the MQOPEN call, as in those case, either intentianally or not, the app is saying only place this message to a q if it exists on this local QM. QMAliases will not somehow figure out that you do not want to go to the local QM, because sometimes, you will want to go to the local QM, and other times, most times, you will not.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 29, 2005 1:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
For situation C, yes, you do need a QM Alias on the gateway advertising every QM that is outside of the cluster, no way around that.
But for A and B, you just do not need QM aliases for QMs in the cluster defined anywhere in the cluster. And even if you did have them, they wont help in the cases where the app specifys the local QM on on the MQOPEN call, as in those case, either intentianally or not, the app is saying only place this message to a q if it exists on this local QM. QMAliases will not somehow figure out that you do not want to go to the local QM, because sometimes, you will want to go to the local QM, and other times, most times, you will not. |
Peter for A you do not create a qmgr alias for the qmgr but for the cluster. The resolution is then a blank qmgr. This is what I call a cluster alias:
QM1 QM2 and QM3 are part of CL1.
Now I can define a clustered alias:
| Code: |
| def qr(CL1) rqmname(' ') cluster(CL1) |
and ask for any clustered queue CLQX in CL1 to be the reply to queue:
queue uri = "queue://CL1/CLQX" which will get resolved to any of the local instances of CLQX in the cluster.
If on A you need a specific instance of the cluster you don't need the cluster alias, just specify the qmgr of that instance, the cluster will know the route.
Situation B the reply to queue just holds the qmr name. No aliases and as you rightly pointed out the cluster will know how to route.
My point was not to define x number of aliases (note only 1 cluster alias is needed) but not to leave the field blank in the reply to qmgr at any time.
Enjoy |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 29, 2005 2:22 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
OK we were talking about 2 different things. I thought you were saying create QM Aliases for QM1, QM2 and QM3, which are not needed. You were if fact talking about a QM Alias for the cluster name, which is needed if apps or remote q defs aim at CL1 as the destination QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 29, 2005 2:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Or if you do not need a specific queue in the cluster as reply to queue:
MDB listening on the reply to queue putting the information into a DB and using load balancing throughout the cluster.... |
|
| Back to top |
|
|
|
|
