[
https://issues.apache.org/jira/browse/SLING-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904176#comment-13904176
]
Carsten Ziegeler commented on SLING-3383:
-----------------------------------------
I've committed some changes, basically now the interrupt flag is reset and in
some cases the running flag is changed.
What's the easiest way to find out if that fixes the problem?
> 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
> 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)
