| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Questions about listener |
« View previous topic :: View next topic » |
| Author |
Message
|
| ALCSALCS |
 Posted: Wed Apr 21, 2004 5:48 am Post subject: Questions about listener |
 |
|
Acolyte
Joined: 14 Apr 2002
Posts: 61
|
In our environment we have one QMGR 'A' production (V5.2) running on MVS who listens at port 1414.
This QMGR was running and has three pair of Sender/Receiver channels and two channels SVRCONN (Client1 and Client2).
At certain time another QMGR 'B' test (V5.2) was started in the same box than MQ manager 'A'. This QMGR has defined only one pair of Sender/Receiver channel.
By mistake the listener for this QMGR 'B' was started at port 1414.
An error message was received
'CSQX218E' Listener unable to bind to port 1414' and after
'CSQX234I' Listener stopped.
Reason : Port 1414 was used by listener from QMGR 'A'.
After 60 seconds QGMR 'B' (parameter LSTRTMR=60), retry to start the listener at port 1414 and this time was succesfully.
After this we saw a different behaviour for clients (V5.3) running in windows trying to connect to SVRCONN 'Client1' and 'Client2'
Client trying to connect to SVRCONN 'Client1' QMGR 'A' continue to work OK but
client trying to connect to SVRCONN 'Client2' QMGR 'B' was receiving error 2059.
Questions:
1) Why Client trying to connect to SVRCONN 'Client1' continue to work OK ?
2) Why client trying to connect to SVRCONN 'Client2' was receiving error 2059 ?.
The answer to 2) is because it was accesing really QMGR 'B', who has not defined any channel 'Client2'.
3) Is it possible to put something in place to prevent this to happens again
'By mistake Test QMGR 'B' trying to start a listener at the same port than Production QMGR 'A' ?
Many Thanks for any help.
Claudio |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Fri Apr 23, 2004 6:45 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
From your scenario i would still think that the listener for QMGR A is the one that is active. And here are the justifications to proove it.
-If a listener is listening on port 1414, for example, and another listener process tries to bind to this same port, the second listener gets an error that you noticed. And it would keep getting this error unless and until the 1st listener ends/dies or somehow releases that listener port. And since you did not mention any of this happening, i would still expect the 1st listener to be active and using 1414.
-Client2 trying to connect to QMGR B got 2059 because your listner is running on 1414 and pertains to QMGR A and hence it comes back saying qmgr not available.
So, the issue of your 3rd question doesnt arise at all, if above theories are true.
Cheers
Kumar |
|
| Back to top |
|
|
| ALCSALCS |
| Posted: Fri Apr 23, 2004 8:26 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2002
Posts: 61
|
09:07:50 CSQX251I +MQCT CSQXSTRL Listener started, TRPTYPE=TCP
09:07:53 CSQX218E +MQCT CSQXLSTT Listener unable to bind to port 1414
09:07:53 CSQX234I +MQCT CSQXLSTT Listener stopped, TRPTYPE=TCP
09:08:53 CSQX251I +MQCT CSQXSTRL Listener started, TRPTYPE=TCP
09:08:53 CSQX023I +MQCT CSQXLSTT Listener started for port 1414
We observed the following above messages on QMGRB(MQCT), but additionally we know that QMGRA was still working okay using 1414, because it has MQClient applications connecting to it, and also we have SND/RCV channels which we observed to be working normally to QMGRA.
Additionally we did not get any error specifying that the listener had stopped on QMGRA.
The errors we started to have was from one MQClient application on WIN2000, which was now connecting to QMGRB, the errors it started getting were 2059, because normally it goes to QMGRA not QMGRB, and the SVRCONN channel definitions do not exisit on QMGRB.
What we do not understand is
1) How on QMGRB the listener started on 1414 eventhough there was an initial error when an attempt was made to start it, and 1414 is in use by QMGRA, and no error was logged for listener terminating on QMGRA.
2) How once the listener had started on QMGRB, on 1414, as shown in above messages that some MQClient applications were still able to connect to QMGRA and were working okay, but another MQClient application was not?
Thanks for any further comments. |
|
| Back to top |
|
|
| bbburson |
| Posted: Fri Apr 30, 2004 10:41 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| ALCSALCS wrote: |
| 2) How once the listener had started on QMGRB, on 1414, as shown in above messages that some MQClient applications were still able to connect to QMGRA and were working okay, but another MQClient application was not? |
I think the answer to this part is that the clients are still connected from the earlier time when QMGRA had the 1414 port. I've seen similar things on UNIX servers when we changed from inetd listener to mq-listener. The 'amqcrsta' connection processes that were active under inetd remained active even when inetd was no longer listening on the port.
The other part about how QMGRB was able to bind to port 1414 is a mystery; it should not happen that two listeners can use the same port at the same time.
Bruce Burson |
|
| 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
|
|
|
|
