[jira] [Created] (SLING-3383) Non stopping thread in AbstractJobQueue causes classloader leak

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-3383:
--------------------------------------

             Summary: Non stopping thread in AbstractJobQueue causes 
classloader leak 
                 Key: SLING-3383
                 URL: https://issues.apache.org/jira/browse/SLING-3383
             Project: Sling
          Issue Type: Bug
          Components: Extensions
    Affects Versions: Event 3.3.4
            Reporter: Chetan Mehrotra


While analyzing heap dump for classloader leaks using script [1] following 
possible leak was reported 

{noformat}
        org.apache.sling.event.impl.jobs.queues.AbstractJobQueue$1@0x12547e960
         Following are few of the live paths found
         Live path
                
org.apache.sling.event.impl.jobs.queues.AbstractJobQueue$1@0x12547e960
                java.lang.Thread@0x12547e888
                [Ljava.lang.Thread;@0x124f18f58
                java.lang.ThreadGroup@0x123346e80
                java.lang.Thread@0x126635c48
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x13161da50
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253e0
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253c0
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x1318253a0
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a128c90
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c198
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c178
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c158
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c138
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c118
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0f8
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0d8
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c0b8
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c098
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c078
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a24c058
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007e30
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007e10
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007df0
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007dd0
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007db0
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007d90
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@0x12a007d70
                
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@0x125d2c968
                java.lang.Thread@0x126637b00
                java.util.concurrent.ThreadPoolExecutor$Worker@0x126637b68
                java.util.HashMap$Entry@0x126640058
                [Ljava.util.HashMap$Entry;@0x12663fde8
                java.util.HashMap@0x125d2ca08
                java.util.HashSet@0x125d2c9f8
                java.util.concurrent.ThreadPoolExecutor@0x125d2c8a0
                
org.apache.sling.commons.threads.impl.DefaultThreadPool@0x125d2c7b0 [*]
                
org.apache.sling.commons.threads.impl.ThreadPoolFacade@0x125d2c798 [*]
                
org.apache.sling.commons.threads.impl.DefaultThreadPoolManager$Entry@0x125d535d0
 [*]
                java.util.HashMap$Entry@0x125d535b0
                [Ljava.util.HashMap$Entry;@0x124147940
                java.util.HashMap@0x124147910
                
org.apache.sling.commons.threads.impl.DefaultThreadPoolManager@0x124146e50 [*]
                org.apache.felix.framework.ServiceRegistrationImpl@0x12414f3e8
                org.apache.sling.commons.threads.impl.Activator@0x12414f3d0 [*]
                org.apache.felix.framework.BundleImpl@0x122809f78
                org.apache.felix.framework.ServiceRegistrationImpl@0x1241e8c40
                class org.apache.sling.commons.threads.impl.WebConsolePrinter
                
org.apache.sling.commons.threads.impl.WebConsolePrinter@0x1241e8a70 [*]
{noformat}

It appears that the thread created in AbstractJobQueue [2] is not interrupting 
the thread upon deactivation/shutdown. So the thread remains blocked in waiting 
(in take method of various implementations) and never gets a chance to check 
for the running flag. A better way would be to handle the InterruptedException 
properly [3] and exit the thread as part of InterruptedException exception 
handling

[1] https://gist.github.com/chetanmeh/8860776 
[2] 
https://github.com/apache/sling/blob/trunk/bundles/extensions/event/src/main/java/org/apache/sling/event/impl/jobs/queues/AbstractJobQueue.java#L161
[3] http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)