|
|
|
| Re: Shutdown issues [message #662652 is a reply to message #662638] |
Thu, 31 March 2011 08:48   |
Eclipse User |
|
|
|
Thanks for the thread dump. It shows the following non-daemon threads (which could be holding up JVM termination):
"DestroyJavaVM" prio=10 tid=0x00007fa6e812a000 nid=0x3762 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"RMI Reaper" prio=10 tid=0x00000000412a3800 nid=0x376a in Object.wait() [0x00007fa6efd31000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x000000077682cc38> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <0x000000077682cc38> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:333)
at java.lang.Thread.run(Thread.java:662)
"VM Thread" prio=10 tid=0x00000000411d4800 nid=0x3765 runnable
"GC task thread#0 (ParallelGC)" prio=10 tid=0x0000000041166800 nid=0x3763 runnable
"GC task thread#1 (ParallelGC)" prio=10 tid=0x0000000041168800 nid=0x3764 runnable
"VM Periodic Task Thread" prio=10 tid=0x0000000041278000 nid=0x3773 waiting on condition
Of these the only threads which are not runnable are the DestroyJavaVM thread and the VM Periodic Task Thread, neither of which I would expect to hold up VM termination, and the RMI Reaper thread which appears to be stuck in a wait.
Another possible clue to the problem in the thread stack dump is the heap stats section:
Heap
PSYoungGen total 663552K, used 252258K [0x00000007d22b0000, 0x0000000800000000, 0x0000000800000000)
eden space 576192K, 37% used [0x00000007d22b0000,0x00000007df5fc3b0,0x00000007f5560000)
from space 87360K, 41% used [0x00000007faab0000,0x00000007fcdbc5e8,0x0000000800000000)
to space 87360K, 0% used [0x00000007f5560000,0x00000007f5560000,0x00000007faab0000)
PSOldGen total 1398144K, used 411K [0x0000000776800000, 0x00000007cbd60000, 0x00000007d22b0000)
object space 1398144K, 0% used [0x0000000776800000,0x0000000776866db0,0x00000007cbd60000)
PSPermGen total 43904K, used 43813K [0x0000000766800000, 0x00000007692e0000, 0x0000000776800000)
object space 43904K, 99% used [0x0000000766800000,0x00000007692c9538,0x00000007692e0000)
Permgen looks pretty full and I wonder if some code is trying to allocate permgen space during shutdown (Virgo wouldn't do that itself AFAIK, but some libraries might).
You might try increasing permgen by 10% to see if that helps.
However, there seems to be a general issue with the RMI Reaper thread. I'm wondering if Spring 3.0.5 or the additional bundles in the repository (if they are auto-installed as optional dependencies of Virgo, Spring, etc. during startup) are running into this. I'll ask around to see if this is a known issue with Spring 3.0.5, but that's a long shot.
So please could you try deleting the additional bundles from the repository and start Virgo with the -clean option and see if that affects the shutdown behaviour.
|
|
|
|
|
|
|
|
|
|
| Re: Shutdown issues [message #662969 is a reply to message #662912] |
Fri, 01 April 2011 11:53 |
| Eclipse User |
|
|
|
I'm afraid I'm not familiar with jmx-agent-1.0.2.jar, so it's hard to know how that might be affecting Virgo. Also, I can't vouch for the changes you made to dmk.sh without doing a lot more research.
This feels like it is unlikely to be a Virgo-specific problem. You might try running some kind of simple "hello world" Java program with the same agent and set up. I found a bug in Java by doing that the other day.
Or you might like to raise an enhancement request to cover the use case that led you into changing dmk.sh and adding the agent in the first place.
Another option, of course, is to purchase commercial support for Virgo so that someone can spend more time on your issue.
Hoep that gives you some ideas.
|
|
|
Powered by
FUDForum. Page generated in 0.27986 seconds
Home
