IMQ Broker Not Shutting Down on Win 2000 Server Re-boot
I am using a Windows 2000 Server and have found that during a re-boot the Broker Service (3.5 SP1) is not shutting down completely. The following lines are missing from the log entry created when restarting the server: -
[17/Aug/2004:12:55:55 BST] [B1093]: Shutdown requested by broker administrator
[17/Aug/2004:12:55:55 BST] [B1047]: Shutting down broker...
[17/Aug/2004:12:55:55 BST] [B1077]: Broadcast good-bye to all connections ...
[17/Aug/2004:12:55:55 BST] [B1078]: Flushing good-bye messages ...
[17/Aug/2004:12:55:55 BST] [B1063]: Done
[17/Aug/2004:12:55:55 BST] [B1048]: Shutdown of broker complete.
[17/Aug/2004:12:55:55 BST] [B1066]:Closing: admin@127.0.0.1:1108->admin:1074. Count=0
[17/Aug/2004:12:55:58 BST].
If the Broker service is manually stopped through Services the entries are placed into the log file.
The problem being created is the broker lock file is not cleared when service is not shutdown completely and when the server is restarted the broker service is then unable to launch as it believes an instance of the service is already running. When the lock file is deleted the broker service can be started.
Has anyone experienced this problem before and found a solution?
If any further information is required in this log then please update with required details.
Many thanks in advance.
Dave.
[1423 byte] By [
Dave_P_C] at [2007-11-25 17:40:14]
# 1
Dave,
There are actually two problems. One is the fact that imqbrokerd is not shutting down cleanly on Windows 2000 reboot. I've filed a bug on this (6157943). We're looking into it.
The second problem is a known bug (5041882 Message Queue can't be started if machine shuts down abruptly) which will be fixed in an upcoming release. This is the lock file problem you hit.
The lock file problem is actually not as common as it looks. imqbrokerd has checks to ensure that the lock is valid before refusing to start. The problem is sometimes the hostname in the lock file is fully qualified, but for some reason the hostname used by imqbrokerd to check the lock is not (or vice-versa). Odds are if you removed the domain name from the hostname in the lock file imqbrokerd would start (or added it if it wasn't fully qualified).
I have been unable to reproduce this condition (where the hostname qualification differs), but I've heard of it from two people (you included). So this must be triggered by either system configuration or timing.
A few questions:
1. What JDK is imqbrokerd using (will be listed in log file)?
2. What are the contents of the lock file?
3. What does the B1029 "broker ready" message say?
thanks,
Joe
jfdp at 2007-7-3 14:35:13 >
# 2
Joe,
Thanks for the response. The further details you require are below:
1)
J2SDK_1_3_1_08 is the version of J2SDK that is installed.
Extracts from the log file regarding versions read: -
Sun Java(tm) System Message Queue
Sun Microsystems, Inc.
Version: 3.5 SP1 (Build 48-G)
Java Runtime: 1.4.2_04 Sun Microsystems Inc.
License: Sun Java(tm) System Message Queue 3.5 SP1 PE License.
Windows 2000 5.0 x86 10.216.17.51 (2 cpu) SYSTEM
2)
The lock file contains only the following line:
imqbroker:257s-bs1a.net.acceptance.co.uk:7676
3)
I am guessing that you mean line B1039 not B1029 which reads :
[B1039]: Broker "imqbroker@10.216.17.51:7676" ready.
Please let me know if this is not correct.
# 3
The fact that the hostname in the lock differs from the hostname in the "broker ready" message is likely an indication of why the lock file is not being reset at startup. When imqbrokerd starts up and finds a lock file it makes sure there is an active imqbrokerd at the host and port in the lock file, plus it checks to see if the lock file is being held by itself. Since the hostname strings are different it thinks the file is held by somebody else. I'm curious as to why these strings are different.
Have you configured any imq.*.hostname properties?
What is your hostname configured to be in Windows?
One thing you can try as a work-around to the lock file problem is setting the following imqbrokerd property:
imq.hostname=257s-bs1a.net.acceptance.co.uk
Joe
jfdp at 2007-7-3 14:35:13 >
# 4
Thanks for your response Joe.
Sorry for the slight delay in getting back to you but in answer to your questions: -
No properties for any imq.*.hostname settings have been configured. All entries have been left as set during the install, which are blank.
The hostname of the server in Windows is 257s-bs1a.
I have not been able to try your suggested work-around as I have been unable to find the imq.hostname setting in any of the IMQ property files. If possible could you please advise where this can be found?
Are there any other files that I can check where IMQ picks up the server host name or IP address?
Thanks for you help,
Dave.
# 5
Dave,
The imq.hostname property is not well documented and does not
appear in the default property files. By default imqbrokerd
uses the local host name, and that appears to be causing the
problem. I'm not familiar enough with windows to know what
configuration settings may be causing the problem.
To try the work around just add this line to the config.properties file:
imq.hostname=257s-bs1a
and see how that works.
jfdp at 2007-7-3 14:35:13 >
# 6
Thanks Joe,
Please read to the end. Thanks to your suggestions I believe I have found the cause of the IMQ Broker problems I was experiencing.
As you suggested by adding the line: -
imq.hostname=257s-bs1a
to the end of the IMQ config.properties file this seems to have worked around the problem shutting down and restarting the IMQ Broker.
Following numerous server restarts the IMQ Broker Service had restarted with Windows successfully. However, I was unable to successfully access the Data Distribution Page.
Further investigation showed the server was using a leased IP address and not static.
I removed the 'imq.hostname' line added earlier and changed the server IP address to static. When the server was rebooted I found the IMQ Service had started successfully. On several successive re-boots the IMQ Broker service restarted with Windows correctly.
To check if this was related to having a dynamic IP address of the server was changed back to Dynamic. Following the first re-boot of the server IMQ had started successfully. On the second re-boot of the server with Dynamic IP the IMQ Broker service did not restart. Following additional re-boots with a dynamic IP address the IMQ Broker service did not restart.
With the IP address changed back to static the server was re-booted. Following the first re-boot the IMQ Broker service had not restarted. Following subsequent re-boots with a static IP address the IMQ Broker service did restart.
Thank you Joe for pointing me in the correct direction.
Regards,
Dave.
