You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2014/02/18 16:50:24 UTC
[jira] [Assigned] (SLING-3383) Non stopping thread in
AbstractJobQueue causes classloader leak
[ https://issues.apache.org/jira/browse/SLING-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler reassigned SLING-3383:
---------------------------------------
Assignee: Carsten Ziegeler
> 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)