[ https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15831495#comment-15831495 ]
Hudson commented on RIVER-447: ------------------------------ SUCCESS: Integrated in Jenkins build River-trunk-jdk7 #193 (See [https://builds.apache.org/job/River-trunk-jdk7/193/]) RIVER-447 Leaked Executor Service Threads in LoadClass Commit reviewed patch. (peter_firmstone: [http://svn.apache.org/viewvc/?view=rev&rev=1779587]) * (edit) src/net/jini/loader/LoadClass.java * (edit) src/org/apache/river/concurrent/RC.java * (edit) src/org/apache/river/concurrent/ReferenceProcessor.java > 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 > Labels: PreferredClassLoader, leaks, threads > Attachments: ExecutorShutdown.patch, River-447.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)