[
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)
