[
https://issues.apache.org/jira/browse/SLING-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-3383.
-------------------------------------
Resolution: Fixed
> 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
> Assignee: Carsten Ziegeler
> Fix For: Event 3.3.6
>
>
> 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)
