| Author |
Message
|
| relheop |
 Posted: Mon Sep 01, 2003 2:38 am Post subject: MQSeries-Listener on Windows2000 |
 |
|
Apprentice
Joined: 30 Jan 2003
Posts: 40
|
We have a problem with a MQSeries-Listener that was started twice for port 1414.
The first listener is started by the MQSeries-Services, where the listener has been marked for starttype automatic and port 1414.
When we looked at the MQSeries-Services-windows we can see only one listener, but looking at the Task-Manager we see a second listener that will start, get an error and is stoopped. A few minutes later the same procedure will start again.
We don't know who started the second listener.
We have installed MQSeries-version 5.2 with CSD02 on Windows2000 server on September 2002.
We have no problems until the last boot of the computer.
Our user said that he only changed the SUBNET-MASK for TCP/IP and therefore they have to restart the computer, but there have been many other restarts in the year ago. |
|
| Back to top |
|
 |
| interactivechannel |
| Posted: Tue Sep 02, 2003 12:34 am Post subject: |
|
|
Voyager
Joined: 20 May 2003
Posts: 94
Location: uk
|
| If you go to IBM for support on this they will only offer limited help, as they only fix the latest CSD. Getting to the latest patch level should be the first step in resolving the issue. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Sep 02, 2003 1:07 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| sometimes INETD is configured to start listeners when ports are opened. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Sep 02, 2003 7:52 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Is there any messages in the event viewer ????
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Tue Sep 02, 2003 9:40 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
We have had similar problems with some of the MQ services, though I'm not sure it's exactly what you are experiencing... Does it show as running in the MQ Services?
What we have seen in the past is if the listener (or another service) is started NOT through services, the services panel doesn't know about it - and will contiue to retry to start the service. You will get an error back (usually ret code 20 or something) which provides no useful information. In most cases it is failing to start because it is already running.
We used to get this all the time when we would setup a channel service... if the channel started before the channel service tried to start it, we would get a message in the error logs and event viewer every minute saying it was unable to start the channel service, ret code 20. It was misleading because though the channel was running, the channel service for that channel said retrying. We worked with IBM to figure out why and it was doing this and finally they advised that we set the "Action to take when service fails" under Recovery to "Take no action". This way the services would try to kick the channel on restart, and if it couln't for any reason the MQ retry logic would kick in and take over and the service wouldn't complain over and over again.
Again, this last scenario was for channel services... I wouldn't recommend setting the Listener service recovery to "take no action" - but it may be that the service recovery logic is what's causing your grief.
Cheers
Steve |
|
| Back to top |
|
|
| relheop |
| Posted: Wed Sep 03, 2003 12:38 pm Post subject: |
|
|
Apprentice
Joined: 30 Jan 2003
Posts: 40
|
Thanks for your mails!
We have messages in the event-log:
1. The Listener is started by the recovery option.
2. The Listener can't connect to port 1414. One failure ... may be it is used.( so it is!)
3. The ret-code 20 is given for the command 'RUNMQLSR -mTIK.QMW043 -t"TCP" -p 1414 '
We have changed "Action to take when service fails" for the listener to "Take no action" and stopped and started the listener(we can't stop the QueueManager because of the running applications), but there was the same situation than before.
We killed the second listener by using the Task-Manager but the listener starts again two minutes later.
Now we have stopped the listener by the MQSeries services.
The result:
We have one listener that was started from the unknown recovery option, but in the MQSeries services the listener is marked as "stopped". The advantage of this no error in the event-log.
For a production-server it isn't a good situation!
We don't know how the now running listener is to become "stopped". |
|
| Back to top |
|
|
|
|
