Menu
▾
▴
#154 JDK 1.6 jmap tool causes wrapper to restart JVM
Hi,
I have configured Java Service Wrapper to start and monitor JBoss application server. This works fine.
Im using JDK 1.6.0 on Redhat Linux.
If I try to dump the heap with the JDK tool jmap, the service wrapper catches a UNKNOWN signal and thinks the JVM has exited and starts an new one. The old JVM is still alive and the heap dump works fine.
Even setting IGNORE_SIGNALS=true in wrapper.sh or
wrapper.ignore_signals=true in wrapper.conf does not fix the problem.
The jmap command i use is the following:
$JAVA_HOME/bin/jmap -F -dump:format=b,file=dump.bin $PID
See also the attached wrapper.log file (with wrapper.debug=true).
wrapper.log
Logged In: YES
user_id=228081
Originator: NO
Ralf,
This is not a feature that I have used in the past myself. I just tried it on a Ubuntu system however, and it all appears to have worked without incident. Here is the command I used to create the dump:
$ /usr/java/jdk1.6.0/bin/jmap -F -dump:format=b,file=dump.bin 31115
Attaching to process ID 31115, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.6.0-b105
Dumping heap to dump.bin ...
Unknown oop at 0xacc83450
Oop's klass is null
Unknown oop at 0xaccdbc50
Oop's klass is null
Heap dump file created
When this ran, there was not any extra output in the wrapper/java process at all even though I had debug enabled.
Can you confirm the output of jmap on your system? There may be some differences in the way things are handled on Ubuntu vs RedHat. I have been reviewing the usage of the waitpid call along with its associated macros. The documentation is not very clear. Some pages seem to imply that it will only show the status of processes which have terminated, while the API itself makes it appear as if it might be possible to get a status even if the child receives a signal. I will look into it more, but if I am unable to reproduce this behavior, I may need to ask you to help out.
Cheers,
Leif
Logged In: YES
user_id=228081
Originator: NO
Ralf,
I think I got this fixed. Can you give the following pre-release version a try?
http://wrapper.tanukisoftware.org/tmp/3.2.4-b/wrapper-linux-x86-32-3.2.4-b.tar.gz
I was assuming that any SIGCHLD received by the wrapper from the jvm was indicating that the JVM had terminated. I think it operating correctly now.
Cheers,
Leif
Logged In: YES
user_id=631446
Originator: YES
Hi Leif,
thanks for the immediate response. Unfortunately the problem is not resolved.
The log messages in wrapper.log changed a bit, but the effect is still the same.
Old (version 3.2.3) wrapper.log entries:
STATUS | wrapper | 2007/01/24 16:50:14 | JVM exited in response to signal UNKNOWN (84).
DEBUG | wrapper | 2007/01/24 16:50:14 | JVM process exited with a code of 1, setting the wrapper exit code to 1.
ERROR | wrapper | 2007/01/24 16:50:14 | JVM exited unexpectedly.
New (version 3.2.4b) wrapper.log entries:
STATUS | wrapper | 2007/01/25 09:10:25 | JVM process is gone.
DEBUG | wrapper | 2007/01/25 09:10:25 | JVM process exited with a code of 1, setting the wrapper exit code to 1.
ERROR | wrapper | 2007/01/25 09:10:25 | JVM exited unexpectedly.
I attached the full wrapper.log file
Maybe, you can have another look at it.
Thanks a lot,
Ralf
File Added: wrapper.log.3.2.4b.ignore_signals
wrapper.log for version 3.2.4b
Logged In: YES
user_id=631446
Originator: YES
Sorry Leif,
i forgot to confirm the jmap output. Here is, what my jmap said:
Attaching to process ID 18510, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 1.6.0-b105
Dumping heap to /tmp/intelliform_2007-01-25.hprof ...
Unknown oop at 0x4376ff20
Oop's klass is 0x634053d0
Unknown oop at 0x44439818
Oop's klass is null
Unknown oop at 0x444f23a8
Oop's klass is 0x444f23b8
Unknown oop at 0x445035a8
Oop's klass is 0x445028c8
Unknown oop at 0x445ec578
Oop's klass is null
Unknown oop at 0x446d5508
Oop's klass is null
Heap dump file created
[root@intelliform bin]#
I think, this looks nearly the same.
Bye, Ralf