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

Shawn Ellis updated RIVER-447:
------------------------------
    Labels: leaks threads  (was: )

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

Reply via email to