| Author |
Message
|
| varunraot |
 Posted: Wed Oct 28, 2015 2:27 am Post subject: Queue Manager with 2 different TCP ports |
 |
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
I have a local broker and queue manager running on Windows Server.
This queue manager is associated to port 1431.
When I tried to connect to this local broker from another server as remote broker, I am able to connect with the port 1431 as well as with port 1432.
The command display lsstatus(LISTENER.TCP) is listing out "1431" as port and not 1432
Any idea about this behavior?
Details
Platform : Windows Server 2008
MQ Version : 7.5.0.1 |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Oct 28, 2015 4:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
With the DISPLAY LSSTATUS command you issued, you asked only about the one LISTENER.TCP listener object, and not any other listener objects that may be defined.
It is also possible that someone or something has started listeners manually with the runmqlsr control command.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| varunraot |
| Posted: Wed Oct 28, 2015 5:08 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
Displaying all status ( display lsstatus(*) ) yielded only LISTENER.TCP which is having port 1431.
Also, LISTENER.TCP is controlled by queue manager
display lsstatus(*)
1 : display lsstatus(*)
AMQ8631: Display listener status details.
LISTENER(LISTENER.TCP) STATUS(RUNNING)
PID(5760)
:
display lsstatus(LISTENER.TCP)
2 : display lsstatus(LISTENER.TCP)
AMQ8631: Display listener status details.
LISTENER(LISTENER.TCP) STATUS(RUNNING)
PID(5760) STARTDA(2015-10-28
STARTTI(02.44.53) DESCR( )
TRPTYPE(TCP) CONTROL(QMGR)
IPADDR(*) PORT(1431)
BACKLOG(100) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 28, 2015 5:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Then you have another queue manager running on that server, and its listener is on port 1432.
Or the DNS name you are using is resolving to 2 or more servers each with a QM running on it each using a listener with a different port. if that's actually the case, may the force be with you, you are gonna need it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| varunraot |
| Posted: Wed Oct 28, 2015 5:51 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
Ah. Peter. You are right.
There is one local queue manager in the same server which is listening on port 1432.
In fact, there are 2 local queue managers in the server.
1. 1st Queue manager - 1432
2. 2nd Queue manager - 1431
When I try to connect to individual queue managers/brokers as a remote broker from a different server by specifying queue manager name, host name, port and server connection channel, it should get connected with their respective connection.
In my case, I can connect to broker ( for 2nd queue manager) with both the port 1431 and 1432. Its not supposed to get connected with 1432 right? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 28, 2015 6:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| varunraot wrote: |
| n my case, I can connect to broker ( for 2nd queue manager) with both the port 1431 and 1432. Its not supposed to get connected with 1432 right? |
Describe how you're connecting to the broker (by which I'm assuming WMB/IIB) through MQ.
MQ doesn't care about queue manager name. It cares about channel name, host name, and port name. So if you use a channel name that exists on both queue managers (like one of the SYSTEM ones, which you shouldn't) then it will connect no matter what queue manager name you use.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 28, 2015 6:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You never need the qmgr name for a client connection. hostname/channel/port is sufficient.
If you are somehow connecting to both qmgrs and both ports, then that's a configuration of the broker, not the server or the queue managers.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| varunraot |
| Posted: Wed Oct 28, 2015 6:42 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
I am connecting via eclipse toolkit ( Brokers - > Connect to a Remote Broker)
I agree that server name, channel name and port name matters while making a remote broker connection
I had same channel name for both the queue managers in the same server say X
1. 1st Queue Manager A - Channel A - 1431 - Broker A
2. 2nd Queue Manager B - Channel A - 1432 - Broker B
Since same attribute channels (with same name) are present , I agree that I was able to connect to broker B with both the ports 1432 and 1431 using queue manager B from server Y
I created one more local queue manager as below in server X
3. 3rd Queue Manager C - Channel A - 1414 - Broker C
However in this case, I was not able to connect to to broker B with port 1414. ( Obvious - MQ 2087 - Unknown Remote Queue Manager) since I am using incorrect queue manager A ( and not C)
Why does same channel principle does not apply here?
SYSTEM.BKR.CONFIG - Channel Info for all 3 queue managers A, B & C
DISPLAY CHANNEL(SYSTEM.BKR.CONFIG)
3 : DISPLAY CHANNEL(SYSTEM.BKR.CONFIG)
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.BKR.CONFIG) CHLTYPE(SVRCONN)
ALTDATE(2015-05-19) ALTTIME(01.38.59)
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) DISCINT(0)
HBINT(300) KAINT(AUTO)
MAXINST(999999999) MAXINSTC(999999999)
MAXMSGL(104857600) MCAUSER( )
MONCHL(QMGR) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) TRPTYPE(TCP) |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 28, 2015 6:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Are you sure both brokers are not accidently sharing the same queue manager?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| varunraot |
| Posted: Wed Oct 28, 2015 6:59 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
Both brokers are having different queue managers - 100 % sure.
Also, both queue managers ( A & B) are having same cluster sender channel and have different cluster receiver channel. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 28, 2015 7:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| varunraot wrote: |
| Also, both queue managers ( A & B) are having same cluster sender channel and have different cluster receiver channel. |
That's a very strange comment to make about a cluster, and speaks to a badly configured cluster.
It also has nothing to do with connecting to the queue manager, or the broker associated with a queue manager.
So to be clear:
- you have queue manager A with broker A associated with it listening on port 1431
- you have queue manager B with broker B associated with it listening on port 1432
- you can connect to broker B from the Toolkit using port 1431
- you're completely certain that when you (for example) deploy code via that connection it goes to broker B not broker A
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| varunraot |
| Posted: Wed Oct 28, 2015 7:23 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
Here is my response:
you have queue manager A with broker A associated with it listening on port 1431 - Correct
you have queue manager B with broker B associated with it listening on port 1432 - Correct
you can connect to broker B from the Toolkit using port 1431 - Well, I can connect to broker B from both 1431 and 1432 from server say Y
you're completely certain that when you (for example) deploy code via that connection it goes to broker B not broker A - Yes. It goes to broker B, when I deploy the code to broker B and it does not go to A.
i.e in my eclipse toolkit, I see 2 identical remote brokers B with same queue managers B ( one with port 1431 and one with 1432). When I make a deployment to broker B, i could see deployment happening and reflecting in both the connections. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 28, 2015 7:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| varunraot wrote: |
| you can connect to broker B from the Toolkit using port 1431 - Well, I can connect to broker B from both 1431 and 1432 from server say Y |
What have you done to prove this? Did you deploy a flow to B that you did not deploy to A?
Did you get a test flow on B to execute when you sent a message to port 1431?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| varunraot |
| Posted: Wed Oct 28, 2015 7:45 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
Yes. I deployed the flow to broker B and not to broker A.
I have also created a queue ( say TEST.IN) under queue manager B and sent a dummy message to it via 2 ways
1. From the local server where I have defined the queue ( i.e Server X - where I have broker A, B and queue manager A & B are present ) using RFH Util.
2. From remote server ( i.e Server Y) using Client RFH Util. Here I could see and verify that TEST.IN is present under the port 1431 and not under port 1432. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 28, 2015 7:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| varunraot wrote: |
Yes. I deployed the flow to broker B and not to broker A.
I have also created a queue ( say TEST.IN) under queue manager B and sent a dummy message to it via 2 ways
1. From the local server where I have defined the queue ( i.e Server X - where I have broker A, B and queue manager A & B are present ) using RFH Util.
2. From remote server ( i.e Server Y) using Client RFH Util. Here I could see and verify that TEST.IN is present under the port 1431 and not under port 1432. |
How does that prove anything we were asking?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
