[jira] [Updated] (RIVER-447) Leaked Executor Service Threads in LoadClass

["Shawn Ellis (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shawn Ellis updated RIVER-447:
------------------------------
    Attachment: ExecutorShutdown.patch

I've attached a patch that is a hack which calls ExecutorService.shutdown() when it is being removed. This prevents the threads from being leaked, but I realize that this probably not the best solution. Thanks for the help.


> Leaked Executor Service Threads in LoadClass
> --------------------------------------------
>
>                 Key: RIVER-447
>                 URL: https://issues.apache.org/jira/browse/RIVER-447
>             Project: River
>          Issue Type: Bug
>          Components: net_jini_loader
>    Affects Versions: River_3.0.0
>         Environment: Linux with either JDK 1.7 or 1.8
>            Reporter: Shawn Ellis
>         Attachments: ExecutorShutdown.patch
>
>
> I am seeing an overall thread usage increase when using Apache River 3.0. I'm able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that
> LoadClass makes use of a loaderMap that contains an Executor Service. After 10 seconds, the loaderMap will garbage collect the Executor Service, but the Executor Service will not be shutdown. This leaves the Executor Service
> thread still running and waiting for work.
>      How to Reproduce:
>      1. Start up an Apache River 3.0 instance
>      2. Have a client connect to the River instance
>      3. Wait 10 seconds
>      4. Have the client connect to the River instance a second time. The number
>         of threads will have increased.
>      The leaked threads have a stack trace similar to the one below.
>        "net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0" #30149 prio=5 os_prio=0 tid=0x00003fff68f79000 nid=0x5db9 waiting on condition [0x00003ffdc344d000]
>           java.lang.Thread.State: WAITING (parking)
>                at sun.misc.Unsafe.park(Native Method)
>                - parking to wait for  <0x00000000f2955ff0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>                at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>                at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>                at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>                at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>                at java.lang.Thread.run(Thread.java:745)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)