[jboss-jira] [JBoss JIRA] (WFLY-9004) Artemis leaks JGroups channels on reload

[Radoslav Husar (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved JBEAP-11812 to WFLY-9004:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-9004  (was: JBEAP-11812)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Clustering
                           (was: Clustering)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.ER1)


> Artemis leaks JGroups channels on reload
> ----------------------------------------
>
>                 Key: WFLY-9004
>                 URL: https://issues.jboss.org/browse/WFLY-9004
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>
> _Customer Impact:_ If server is reloaded multiple times then there is growing number of threads. This can crash server on OutOfMemoryError. Also threads continuously increases memory footprint.
> If server is reloaded multiple times then there seems to be infinite grow in numbers of following 2 threads:
> {code}
> "thread-2,shared=<CLUSTER>" #158395 daemon prio=5 os_prio=0 tid=0x00007fb5e351c000 nid=0x2672 waiting on condition [0x00007fb5cabaf000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000fc9e6d48> (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 org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> 	at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$868/1712469388.run(Unknown Source)
> 	at java.lang.Thread.run(Thread.java:744)
> {code}
> {code}
> "Timer runner-1,shared=<CLUSTER>" #158327 daemon prio=5 os_prio=0 tid=0x00007fb6bdd50800 nid=0x262b runnable [0x00007fb5d5d5e000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000fc9e76f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
> 	at java.util.concurrent.DelayQueue.take(DelayQueue.java:70)
> 	at org.jgroups.util.TimeScheduler3.run(TimeScheduler3.java:166)
> 	at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> 	at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory$$Lambda$868/1712469388.run(Unknown Source)
> 	at java.lang.Thread.run(Thread.java:744)
> {code}
> There seems to be thread pool executor which is creating new and new thread after each reload waiting for a task to be executed. However number of those threads is not going down and most likely there is not set maximum limit.
> Attaching 2 thread dumps where diff between threads can be made. I've used script https://github.com/dudaerich/scripts/blob/master/src/thread-dump-analyzer.groovy to get number of threads from each thread pool and then made a diff.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)