[jboss-dev] JBoss Embedded AS - JVM keeps running

[Carlo de Wolf]

On 04/15/2010 09:09 PM, Carlo de Wolf wrote:
> On 04/15/2010 07:22 PM, Jaikiran Pai wrote:
>> Jaikiran Pai wrote:
>>> However, there are some non-daemon threads still active even after a
>>> server shutdown:
>>>
>>> "pool-15-thread-1" prio=10 tid=0x8cb1ec00 nid=0x4d13 waiting on
>>> condition [0x8e7a6000]
>>>     java.lang.Thread.State: TIMED_WAITING (parking)
>>>      at sun.misc.Unsafe.park(Native Method)
>>>      - parking to wait for<0xb20d6258>  (a
>>> java.util.concurrent.SynchronousQueue$TransferStack)
>>>      at
>>> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
>>>      at
>>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424) 
>>>
>>>      at
>>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323) 
>>>
>>>      at 
>>> java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)
>>>      at
>>> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945) 
>>>
>>>      at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) 
>>>
>>>      at java.lang.Thread.run(Thread.java:619)
>>>
>>> ...
>>> "pool-5-thread-1" prio=10 tid=0x8cfc2800 nid=0x4ce0 waiting on 
>>> condition
>>> [0x8cdad000]
>>>     java.lang.Thread.State: WAITING (parking)
>>>      at sun.misc.Unsafe.park(Native Method)
>>>      - parking to wait for<0x97ece7e8>  (a
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>>>      at 
>>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
>>>      at
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) 
>>>
>>>      at
>>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) 
>>>
>>>      at
>>> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) 
>>>
>>>      at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) 
>>>
>>>      at java.lang.Thread.run(Thread.java:619)
>>>
>>>
>>> These pool-x-thread-y threads prevent the JVM from shutting down. The
>>> thread names aren't very informative to figure out which service 
>>> started
>>> those threads and why were those not shutdown. Anyone knows what these
>>> threads are for and why they are hanging around after a server 
>>> shutdown?
>>>
>> Thanks to Byteman (http://www.jboss.org/byteman), I was able to figure
>> out what was creating these threads and why they were not cleaned up on
>> shutdown.
>>
>> Out the two threads, one is from ShrinkWrap
>> (http://www.jboss.org/shrinkwrap) which uses an ExecutorService to
>> create a cached thread pool. The thread created out of this pool was
>> staying around idle for 60 seconds (default) which was preventing (or
>> rather contributing to one minute delay in) the standalone client 
>> shutdown.
>>
>> However, the main culprit turns out to be NamingServer in AS which uses
>> an Exceutor backed by the default thread pool factory which creates
>> non-daemon threads
>> http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/etc/deploy/naming-jboss-beans.xml: 
>>
>>
>> <bean name="LookupPool">
>> <constructor factoryMethod="newFixedThreadPool"
>> factoryClass="java.util.concurrent.Executors">
>> <!-- At least 2 threads are required -->
>> <parameter>2</parameter>
>> </constructor>
>> </bean>
>>
>> <bean name="RemoteNamingBean" class="org.jnp.server.Main">
>> ...
>> <!-- The thread pool service used to control the bootstrap lookups -->
>> <property name="lookupExector"><inject bean="LookupPool"/></property>
>> </bean>
>>
>> Locally, I have fixed this by passing a JBossThreadFactory (configured
>> to create daemon threads) to the Executor, so that it doesn't use the
>> default one. I have some questions around the configuration options for
>> JBossThreadFactory, for which I'll create a forum thread. I'll commit
>> the fix after that discussion.
>>
>> By the way, as ALR pointed out on IRC, changing any random thread in AS
>> to mark them as daemon isn't always the right solution. But in case of
>> the NamingServer, IMO, changing it to daemon makes sense. If anyone has
>> objections, feel free to raise them.
>>
>> -Jaikiran
>>
> The clean way would be shutdownNow().
> Now a runaway thread can still keep the server hanging.
>
> Carlo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-development/attachments/20100415/a53d5c29/attachment.html