| Author |
Message
|
| sijtom0703 |
 Posted: Wed Jun 12, 2013 8:29 pm Post subject: How bindings file in mq works |
 |
|
Voyager
Joined: 28 May 2011
Posts: 84
Location: USA
|
I have a set of inbound queues in one queue manager in server A and another set of outbound queues in a different queue manager with same name in server B.
When the Application makes calls through bindings file generated from the below config will the App be able to locate the queues in the correct queue manager?
def qcf(ivtcfA) qmgr(QM1) transport(client) hostname(serverA) channel(SYSTEM.MQS.SVRCONN) port(2434) clientid(App1)
def qcf(ivtcfB) qmgr(QM1) transport(client) hostname(serverB) channel(SYSTEM.MQS.SVRCONN) port(2434) clientid(App1) |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jun 13, 2013 5:07 am Post subject: Re: How bindings file in mq works |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sijtom0703 wrote: |
| I have a set of inbound queues in one queue manager in server A and another set of outbound queues in a different queue manager with same name in server B. |
This is not a good idea. This will confuse WMQ's name resolution and cause you all sorts of problems, like this. Your app will connect to a queue manager by name and to only one queue manager. Hence (depending on which one it finds) one set of queues will not be found.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sijtom0703 |
| Posted: Thu Jun 13, 2013 6:46 am Post subject: |
|
|
Voyager
Joined: 28 May 2011
Posts: 84
Location: USA
|
Thanks Vitor for the reply
I was under the assumption when an Application lookup for an object it looks up to a connection factory first then the objects in that CF.
Here the connection factory points to two different servers which is correctly defined in the config header. So there would be no confusion for Application in identifying the mq objects.
So what do you recommend here. Put all the queues in one queue manager in the same server.? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 13, 2013 6:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sijtom0703 wrote: |
| Here the connection factory points to two different servers which is correctly defined in the config header. So there would be no confusion for Application in identifying the mq objects. |
Well, I'm the last person to take a stand on Java issues. It may be it will work as you say, but if you're that sure why did you ask? At best you'll have 2 apparently identical connections.
Try it. Post your results.
| sijtom0703 wrote: |
| Put all the queues in one queue manager in the same server.? |
Connections are expensive and should be kept to a minimum. I also repeat my comments about having 2 identically named queue managers on 2 differrent servers. I've yet to see a convinicing benefit from doing this and it causes all sorts of problems.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| calanais |
| Posted: Fri Jun 14, 2013 7:14 am Post subject: |
|
|
Apprentice
Joined: 12 Mar 2010
Posts: 32
|
There are two definitions of connection factories there; each will be bound into JNDI with different names. When the application gets these out of JNDI, it will be able to create a JMS connection from either one.
It looks like you've got two hosts with identically configured QMs? The JMS application will be able to have connections to both of them - depending on which connection you then use to create producers/consumers will control what set of queues are used.
There's no problem with this type of configuration so long as the application knows where it's going to. |
|
| Back to top |
|
|
|
|
