| Author |
Message
|
| jainvik7 |
 Posted: Fri Nov 10, 2006 11:56 pm Post subject: Listener setup |
 |
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
Hello All,
I have an MQ setup with three QMGRS on sun solaris server. We use this for our test enviroment. Last night I stopped all the qmgrs and saw that all the processes were down apart from the listener process. "runmqlsr ".
I waited for some time for it to go down but it didn't. In the meanwhile one of my colleagues seeing all the qmgrs down started them without knowing that I had stopped the qmgrs. Surprisingly all the qmgrs went up and the channels between them started working fine. Remember, the listener processes from the previous start were not killed. But, still the everything was fine. We dont use the inetd.conf/services file to configure the listeners.
My question is, l can a qmgr refer to the previous listener process. Hope I am clear with my question. To be frank, this seems to be a bit strange.
Please do send in your comments/suggestions.
Thanks |
|
| Back to top |
|
 |
| hopsala |
| Posted: Sat Nov 11, 2006 2:36 am Post subject: Re: Listener setup |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jainvik7 wrote: |
| My question is, l can a qmgr refer to the previous listener process. |
AFAIK the answer is no. In all cases that I can remember, if a listener is left up after shutdown, upon restart the QM starts but remains without a listener, since the port is taken by the listener that stayed up.
But keep in mind that listeners are not in charge of channels per-se, only on receiver channels; so the question is what you meant by:
| jainvik7 wrote: |
| Surprisingly all the qmgrs went up and the channels between them started working fine... |
Which channels went up? If senders, then that's fine - the channel initiator brought them up; but if you're talking about receivers, then you do have something a bit funky on your hands (although I have yet to work with WMQ on solaris - what I say applies to windows and other unix flavors)
Of course, there's always the option that your startup script includes a "kill listener" command, or that the guy who brought them up killed the orphaned listener... |
|
| Back to top |
|
|
| jainvik7 |
| Posted: Sat Nov 11, 2006 3:23 am Post subject: |
|
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
jainvik7 wrote:
Surprisingly all the qmgrs went up and the channels between them started working fine...
I am actually talking about the rcvr channels. Though I have both sdr and rcvr channels for my qmgrs.
Of course, there's always the option that your startup script includes a "kill listener" command, or that the guy who brought them up killed the orphaned listener...
No ... the previous listeners were never killed. Infact i had them on my session/screen and was waiting for them to go down.  And in very short intervals I was issuing the "ps -ef| grep -i runmqlsr" and was monitoring the PIDs. |
|
| Back to top |
|
|
| jainvik7 |
| Posted: Sat Nov 11, 2006 3:44 am Post subject: |
|
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
Kindly have a look at the output for the "ps -ef | grep -i mqm" and have a look at the timestamp of the other qmgrs processes and the runmqlsr processes.
mqm 18200 18195 0 20:08:59 ? 0:00 /opt/mqm/bin/amqzdmaa -m BT.QM.ARYAA0T4
mqm 14214 14211 0 11:04:37 ? 0:00 amqzllp0 -mBT.QM.ARYAA0T5 ?
mqm 18196 18195 0 20:08:58 ? 0:00 /opt/mqm/bin/amqzfuma -m BT.QM.ARYAA0T4
mqm 13383 13376 0 10:52:27 ? 0:02 amqzlaa0 -mBT.QM.ARYAA0T3 -fip0
mqm 13376 1 0 10:52:26 ? 0:00 amqzxma0 -m BT.QM.ARYAA0T3
mqm 13974 1 0 Apr 17 ? 0:08 runmqlsr -m BT.QM.ARYAA0T4 -t tcp -p 1818
mqm 14626 13376 0 15:07:34 ? 0:00 amqzlaa0 -mBT.QM.ARYAA0T3 -fip2
mqm 14722 1 0 Jun 13 ? 0:02 runmqlsr -m BT.QM.ARYAA0T3 -t tcp -p 51441
mqm 13379 13376 0 10:52:27 ? 0:00 amqzllp0 -mBT.QM.ARYAA0T3 ?
mqm 14212 14211 0 11:04:36 ? 0:00 /opt/mqm/bin/amqzfuma -m BT.QM.ARYAA0T5
mqm 18043 14211 0 15:30:10 ? 0:00 amqzlaa0 -mBT.QM.ARYAA0T5 -fip2
mqm 15830 1 0 Jun 12 ? 0:01 runmqlsr -m BT.QM.ARYAA0T5 -t tcp -p 51440
mqm 18198 18195 0 20:08:59 ? 0:01 amqzllp0 -mBT.QM.ARYAA0T4 ?
mqm 14218 14211 0 11:04:38 ? 0:00 /opt/mqm/bin/runmqchi -m BT.QM.ARYAA0T5
mqm 18044 1 0 15:30:15 ? 0:00 /opt/mqm/bin/runmqchl -c ARYAAT5.TO.DEVBOX -m BT.QM.ARYAA0T5
mqm 14625 1 0 15:07:34 ? 0:00 /opt/mqm/bin/runmqchl -c ARYAAT3.TO.DEVBOX -m BT.QM.ARYAA0T3
mqm 14294 1 0 Jun 05 ? 0:01 runmqlsr -m BT.QM.ARYAA0T3 -t tcp -p 51434
mqm 13380 13376 0 10:52:27 ? 0:00 /opt/mqm/bin/amqrrmfa -t2332800 -s2592000 -p2592000 -g5184000 -c3600 -m BT.QM.A
mqm 13382 13376 0 10:52:27 ? 0:00 /opt/mqm/bin/runmqchi -m BT.QM.ARYAA0T3
mqm 13628 14722 0 10:55:15 ? 0:00 /opt/mqm/bin/amqrmppa -m BT.QM.ARYAA0T3
mqm 18195 1 0 20:08:58 ? 0:01 amqzxma0 -m BT.QM.ARYAA0T4
mqm 18202 18195 0 20:08:59 ? 0:41 amqzlaa0 -mBT.QM.ARYAA0T4 -fip0
mqm 19658 18201 0 20:58:29 ? 0:00 /opt/mqm/bin/runmqchl -c ARYAA.TO.DEVBOX -m BT.QM.ARYAA0T4
mqm 14211 1 0 11:04:36 ? 0:00 amqzxma0 -m BT.QM.ARYAA0T5
mqm 19648 18195 0 20:48:59 ? 0:00 amqzlaa0 -mBT.QM.ARYAA0T4 -fip4
mqm 14216 14211 0 11:04:38 ? 0:00 /opt/mqm/bin/amqrrmfa -t2332800 -s2592000 -p2592000 -g5184000 -c3600 -m BT.QM.A
mqm 13377 13376 0 10:52:27 ? 0:00 /opt/mqm/bin/amqzfuma -m BT.QM.ARYAA0T3
mqm 14251 15830 0 11:05:10 ? 0:00 /opt/mqm/bin/amqrmppa -m BT.QM.ARYAA0T5
mqm 18320 13974 0 20:10:07 ? 0:01 /opt/mqm/bin/amqrmppa -m BT.QM.ARYAA0T4
mqm 18197 18195 0 20:08:59 ? 0:09 amqhasmx BT!QM!ARYAA0T4 /var/mqm
mqm 18199 18195 0 20:08:59 ? 0:00 /opt/mqm/bin/amqrrmfa -t2332800 -s2592000 -p2592000 -g5184000 -c3600 -m BT.QM.A
mqm 14217 14211 0 11:04:38 ? 0:00 /opt/mqm/bin/amqzdmaa -m BT.QM.ARYAA0T5
mqm 13378 13376 0 10:52:27 ? 0:00 amqhasmx BT!QM!ARYAA0T3 /var/mqm
mqm 18201 18195 0 20:08:59 ? 0:00 /opt/mqm/bin/runmqchi -m BT.QM.ARYAA0T4
mqm 14213 14211 0 11:04:36 ? 0:07 amqhasmx BT!QM!ARYAA0T5 /var/mqm
mqm 14219 14211 0 11:04:38 ? 0:08 amqzlaa0 -mBT.QM.ARYAA0T5 -fip0
mqm 13381 13376 0 10:52:27 ? 0:00 /opt/mqm/bin/amqzdmaa -m BT.QM.ARYAA0T3 |
|
| Back to top |
|
|
| wschutz |
| Posted: Sat Nov 11, 2006 3:51 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Which version of MQ? V5.3? V6?
V6 introduces listener "objects" which can be defined to start/stop with the qmgr. Otherwise look at "endmqlsr".... otherwise its "normal" for listeners to be running even without a qmgr running ....
_________________
-wayne |
|
| Back to top |
|
|
| jainvik7 |
| Posted: Sat Nov 11, 2006 4:05 am Post subject: |
|
|
Apprentice
Joined: 19 Feb 2006
Posts: 38
|
I am using ver5.3.
Shouldn't the listener process come down when the qmgr is shut down ??? |
|
| Back to top |
|
|
| wschutz |
| Posted: Sat Nov 11, 2006 4:45 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Nov 11, 2006 6:05 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
As wayne said, the listener does not come down when the qm does, you have to end it yourself in 5.3. So if you have orphaned listeners up and running after a restart, that's not surprising really.
However, you claim that even though the listener did not come down, you restarted the QM and receivers went up nontheless - and that, if true, is odd indeed. Now, Let's have a look at what you posted:
First off, you forgot to mark one of the listeners (the fourth):
| Code: |
mqm 13974 1 0 Apr 17 ? 0:08 runmqlsr -m BT.QM.ARYAA0T4 -t tcp -p 1818
mqm 14722 1 0 Jun 13 ? 0:02 runmqlsr -m BT.QM.ARYAA0T3 -t tcp -p 51441
mqm 15830 1 0 Jun 12 ? 0:01 runmqlsr -m BT.QM.ARYAA0T5 -t tcp -p 51440
mqm 14294 1 0 Jun 05 ? 0:01 runmqlsr -m BT.QM.ARYAA0T3 -t tcp -p 51434 |
Note that you have here two listeners for the same qm on a different port, is it possible that you have some script which selects a random/unused port? How exactly do you start the listeners when QM starts?
Second, I only see here sender channels, which is quite natural - i'm not supposed to see receivers here. Did you check the receiver channel status in runmqsc and see that they're running?
Third, did this happen only once? Did you manage to recreate it?
Fourth and most important - you didn't quite clarify in which of these QMs the problem lies; which one of these allegedly "reconnects" to the orphaned listener? |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Sat Nov 11, 2006 6:25 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
I am a little confused here. I admit that I don't know the internals of RUNMQLSR but I don't exactly see why bringing the queue manager down would cause it a problem (if it is written correctly)
It could easily detect the qmanger quiescing and disconnect, then detect that it starts back up again and reconnect. AFAIK runmqlsr is just an application program using regular API calls isn't it? The IP side of things didn't change (same port number that it is listening on) so I don't understanding why it would have to cause a problem.
If this isn't how it is coded then I would have at least expected IBM to have code in the program to shutdown itself down if the end manager is shutdown. They preach and teach that applications detect this so I would have thought they took their own advice and coded for this. 
Having said that I have never tried this scenario so I could be talking out of my...well you know what |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Nov 11, 2006 8:36 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| kevinf2349 wrote: |
| If this isn't how it is coded then I would have at least expected IBM to have code in the program to shutdown itself down if the end manager is shutdown. They preach and teach that applications detect this so I would have thought they took their own advice and coded for this. |
I couldn't agree more; it seems like the easiest thing in the world - listener sees that qm is down, and courteously shuts itself down.
But the reality is that since the birth of MQ, for whatever reason, listeners (especially on unix OSs) needed to be manually shut down. That's just the way it is...
My personal theory is that the listener in itself is not an WMQ application, and is not even linked with WMQ libraries (so as to keep it portable, which also explains the possibility of inted listeners even working) and that all it knows to do is to listen at a port, and run a channel thread. Due to this, it actually has no way to notice when a QM is down. However, you'd think IBM would write a be able to small prog which does nothing but see if a qm is up, so that the listener could run it every now and again and see what's going on.
There is probably something more to this, I trust IBM enough to assume that if something isn't fixed by V6, it's either impossible or counter-design. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Nov 11, 2006 1:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Guys.... Remember your 5.3 days.
The startup/shutdown sequence used to be:
- start listener (background)
- start qmgr
- start trigger Monitor
- start command server
- do work
- shutdown command server
- shutdown qmgr (takes care of trigger monitor)
- shutdown listener
So it is clear from this list and the fact that the listener was always started with the qmgr argument and port, that the listener acted as daemon and knew which QMGR it was to service...
So there is no such thing as an orphaned listener. There is only a listener without qmgr running. You restart the qmgr everything works fine...
Yes V6 has given us much more control and the possibility to start and stop the listener automatically with the qmgr.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
