Thanks Shawn,

A way to make this patch less of a hack would be to have ReferenceProcessor check for instances of Closable, since this is a standard way of closing resources, we could document this as a feature of RC.

The ExecutorService would then be decorated with a Closable ExecutorService, to make this reusable we can provide a standard Closeable ExecutorService decorator in org.apache.river.thread.

I think this is a driver for River 3.0.1

Regards,

Peter.

On 15/01/2017 1:36 AM, Shawn Ellis (JIRA) wrote:
      [ 
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