| Author |
Message
|
| fjb_saper |
 Posted: Mon Feb 07, 2005 12:40 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
One more question:
Get commands addressed to devices when they are not listening ?
How do these commands need to be treated ?
If the queues should be permanent why not have a little PCF part that creates the queue (and adds it to the cluster ? see my comment down the line)
Don't forget that you would not really enjoy any load balancing as you have one queue per device and really only one local queue to read from.
Load balancing through clustering can help where your command server is concerned. One command server or five in the cluster does no longuer matter and you can load balance the command servers.
There is no easy way to load balance the devices. The only way I see load balancing the devices is some kind of load balancing TCP/IP device that will give you the least busy qmgr. So you would use this balancers IP and get redirected to the host with the least load. All qmgrs need to have the same svrconn chl and port...??
Create a dynamic queue and pass it to the server in the reply to q and qmgr fields
Enjoy  |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Feb 07, 2005 12:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| jefflowrey wrote: |
| If he created QM aliases on his "server" queue manager for all of his client QMs (not client Q's), would that allow the server program to use an MQOPEN with dynamic queue name and requested QM name, and have the resolution work and use the CLUSTER channels to reach the right QM? |
Here is what I did, and it worked, allowing the use of dynamic queues in thic scenario, while taking advantage of clustering channels for reduced administration.
QM1, QM2 and QM3 are in CLUSTER1.
QM2 has a QMAlias called QM2 that is clustered. (Blank RQNAME and XMITQ, QM2 for the RQMName)
QM3 has a QMAlias called QM3 that is clustered. (Blank RQNAME and XMITQ, QM3 for the RQMName)
QM2 has a local queue called APPLE. APPLE is not clustered.
QM3 has a local queue called BEAR. BEAR is not clustered.
QM1 is the QM that the command putter connects to.
The command putter knows it needs to put a messages to APPLE on QM2. If it connects to QM1, and does an MQOPEN specifying APPLE and QM2, the messages do make it to APPLE on QM2 when it starts putting, even though APPLE is not clustered!  Don't see how APPLE or BEAR being regular local queues versus dynamic local queues would effect this test.
So, in this fashion, as long as the command putter knows the queue name AND hosting queue manager of that queue, and there is a QMAlias defined on every QM in the cluster, this should work just fine.
Good idea Jeff.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mhubbard |
| Posted: Mon Feb 07, 2005 12:50 pm Post subject: |
|
|
Acolyte
Joined: 25 Aug 2004
Posts: 54
|
If a device is not listening (and thus, under my current architecture, no queue exists) the command is left in DB2 from whence it came and will be tried again later.
We have such a balancing program that we use here. I have also coded the client to read in as many queue manager names and channel names as we care to have from a config file and then randomly pick one to begin with. I know this isn't true load balancing, but it would at least spread things out.
I can't get past the GET problem, however. Maybe I don't understand something, but I am under the impression that even if I define my queues by hand and make them cluster queues, that this does me no good from the client side because I still have to know which queue manager has that queue defined as local.
_________________
Michael J. Hubbard |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 07, 2005 12:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| mhubbard wrote: |
| Maybe I don't understand something, but I am under the impression that even if I define my queues by hand and make them cluster queues, that this does me no good from the client side because I still have to know which queue manager has that queue defined as local. |
This is correct.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mhubbard |
| Posted: Mon Feb 07, 2005 1:05 pm Post subject: |
|
|
Acolyte
Joined: 25 Aug 2004
Posts: 54
|
Thanks so much to everyone.
Sounds like I will build a little "This is where I am" queue and have each client put a message on it telling where he is attached. The command putter will listen on that queue and keep track of where to send things. Then I will use the technique of QM aliases to get the message to the right spot.
I really appreciate that you went so far as to test somethng out.
_________________
Michael J. Hubbard |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Feb 07, 2005 1:15 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| mhubbard wrote: |
| Sounds like I will build a little "This is where I am" queue and have each client put a message on it telling where he is attached. The command putter will listen on that queue and keep track of where to send things. Then I will use the technique of QM aliases to get the message to the right spot. |
This queue should be a local queue, and could be a clustered queue. Then you could potentially put multiple instances of your command putter out there - as long as there weren't message affinity issues or issues with the command putter application where it would step on it's own toes.
Peter's idea of putting the QMAlias on the QM it points to, and sharing it in the cluster is a really good one, too. It means you don't have to change *anything* other than the affected queue manager when you want to add or drop one.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Feb 08, 2005 12:16 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
| jefflowrey wrote: |
| Peter's idea of putting the QMAlias on the QM it points to, and sharing it in the cluster is a really good one, too. It means you don't have to change *anything* other than the affected queue manager when you want to add or drop one. |
Although it works there is a little downside to this, using the QMAlias and ' blanking' the Qmgr causes the cluster to pass the message to the ' next' QMgr if that Qmgr knows about the LocalQ it will put it there, if not it will pass it to the next and so on. I don't know how the Qmgr knows who is the next, so this should be tried with a larger cluster and not just 2 or 3 Qmgrs. Potentially the message could go bouncing between 2 qmgrs that think they are each others 'next'...
I have not verified this theory, but I would make sure the above does not happen...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Feb 08, 2005 12:25 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
Additionally... why not simply use the ReplyToQmgr id of the 'gimme my commands' message sent from the client? using a dynamic queue on any of the qmgrs part of the cluster should be enough for the 'putter' to find it's way back to the proper localQ.
Cluster: QMA, QMB, QMC, QMPutter
ClusterQ: Putter on QMPutter
Clients connect to either QMA, QMB or QMC and put 'gimme my commands' on Putter.
Putter app reads Putter and sees this is coming from Q XYZ (Client id) on QMA, QMB or QMC (in the reply to Qmgr field) and puts the commands back to that specific Queue. The cluster knows how to find QMA, QMB and QMC, the Qmgr will take care of the rest.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Feb 08, 2005 5:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| MichaelDag wrote: |
| Additionally... why not simply use the ReplyToQmgr id of the 'gimme my commands' message sent from the client? using a dynamic queue on any of the qmgrs part of the cluster should be enough for the 'putter' to find it's way back to the proper localQ. |
I think we covered that.
| jefflowrey wrote: |
| the client app would create the dynamic queue and then send a request message to the server app. This could very clearly hold the destination QM as well as the Q name of the dynamic queue. |
| MichaelDag wrote: |
| The cluster knows how to find QMA, QMB and QMC, the Qmgr will take care of the rest. |
That's what we were trying to use the QMAliases for. Are you suggesting that we can get away without using those?
Also, I thought that in clusters, the cluster would open up a dynamic channel from QMA directly to QMC if QMA needed to send a message to QMC. So there would never be an intermediate hop, unless there were specific QM aliases set up to make that happen.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 08, 2005 6:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| MichaelDag wrote: |
| jefflowrey wrote: |
| Peter's idea of putting the QMAlias on the QM it points to, and sharing it in the cluster is a really good one, too. It means you don't have to change *anything* other than the affected queue manager when you want to add or drop one. |
Although it works there is a little downside to this, using the QMAlias and ' blanking' the Qmgr causes the cluster to pass the message to the ' next' QMgr if that Qmgr knows about the LocalQ it will put it there, if not it will pass it to the next and so on. I don't know how the Qmgr knows who is the next, so this should be tried with a larger cluster and not just 2 or 3 Qmgrs. Potentially the message could go bouncing between 2 qmgrs that think they are each others 'next'...
I have not verified this theory, but I would make sure the above does not happen... |
Michael, I'm afraid I don't follow. The QMAlias defs are not blanking out the QM name. QMX has a QMAlias defined as follows:
| Code: |
DEFINE QREMOTE ('QMX') +
XMITQ(' ') +
RNAME(' ') +
RQMNAME('QMX') +
CLUSTER('CLUSTER1') +
REPLACE
|
The purpose is so that any QM in the cluster that finds itself with a message addresses for QueueWhatever on QMX will be able to use cluster channels to get to QMX. This seems to work in my tests whether QueueWhatever is clustered or not, which is good in this problem, because the dynamic queues cannot be clustered.
I don't see anyway for the messages to bounce around.
Your idea for getting the command putter to know the destination QM from the ReplyToQM field is a good one, but without the clustered QMAliases, you would then need to define XMITQs and SNDR/RCVR channels all over the place. This certainly is a feasible approach if you don't have a cluster to take advantage of. In THAT scenario, a Hun and Spoke design is keen. The command putter connects to QMHub. You can add Spoke QMs without any other changes to existing SPoke QMs.
But if you are already in a cluster (for other reasons, as clustering is no benifit in this specific case), then you might as well take advantage of it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Feb 08, 2005 6:16 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| But if you are already in a cluster (for other reasons, as clustering is no benifit in this specific case), then you might as well take advantage of it. |
Actually clustering is specifically an advantage in this case because then you don't] have to fully connect your network with direct channels.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Feb 08, 2005 6:17 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
| jefflowrey wrote: |
| That's what we were trying to use the QMAliases for. Are you suggesting that we can get away without using those? |
I thought so... blur of the moment? or could it work as there will always be only one instance dynamic client queue on QMA, QMB or QMC and you don't need to cluster to do round robin as you already know where the message needs to go.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 08, 2005 6:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| jefflowrey wrote: |
| PeterPotkay wrote: |
| But if you are already in a cluster (for other reasons, as clustering is no benifit in this specific case), then you might as well take advantage of it. |
Actually clustering is specifically an advantage in this case because then you don't] have to fully connect your network with direct channels. |
Weeeeellllllll OK.
If I had 4 QMs to interconnect, it is true clustering would make it so I would have less MQ defs to make. But unless there was a need for load balancing, I would never cluster that. I would take the extra 30 minutes and interconnect the QMs with regular channels.
Now, if those 4 QMs became 400 QMs, and all 400 needed to be inteconnected, then I would definitly consider clustering even if there was no load balancing required.
As cool as clustering is, I still avoid it unless I NEED it. There is still a lot magically happening under the covers. K.I.S.S. I say.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Feb 08, 2005 6:31 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
| Michael, I'm afraid I don't follow. The QMAlias defs are not blanking out the QM name. QMX has a QMAlias defined as follows: |
Peter, sorry for confusing you I had it backwards in my memory... it blanks the XMITQ and so forces the message onto the Cluster XmitQ ... etc... yada yada...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
|
|
