[GLASSFISH-20463] DAS fails to stop with stop-domain --force=false due to a non-daemon thread Created: 03/May/13  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


If you do:

asadmin start-domain
asadmin stop-domain --force=false

You get a timeout:

$ asadmin stop-domain --force=false
Waiting for the domain to stop ........................................................
Timed out (60 seconds) waiting for the domain to stop.
Command stop-domain failed.

This is due to a non-daemon thread in a thread pool. From the jstack output:

"pool-8-thread-1" prio=5 tid=0x00007fa321b71000 nid=0xa103 waiting on condition [0x00000001368d5000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)

  • parking to wait for <0x00000001292d9910> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:722)

Comment by Tom Mueller [ 03/May/13 ]

This thread appears to be coming from the FighterFish ExtenderManager.GlassFishServerTracker class. This class calls Executors.newSingleThreadExecutor but never calls any shutdown method on the executor. The thread that is created by this executor is not a daemon thread.

Please evaluate whether this is a stopper for 4.0.

Comment by Sanjeeb Sahoo [ 06/May/13 ]

At this stage of 4.0 release, I am inclined to not fix this issue. We will fix it in 4.0.1.

Comment by TangYong [ 06/May/13 ]


I also agree with you not fixing the issue in 4.0 and put in 4.0.1. Just as fixing itself, I think that following seems to be reasonable,

1. raising up executorService into GlassFishServerTracker class instance member
2. shutdown logic should be put into removedService method, and once executorService is not null, we execute
executorService.shutdown() and assign executorService is null.


Generated at Mon Feb 08 20:14:41 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.