Description of problem: Created as new BZ based on https://bugzilla.redhat.com/show_bug.cgi?id=1037574#c9 Number of threads before reloading server is 38, after reload is 41. Thus there is still some leak, though you fixed some. I do not say it is in CLI - you can find out which threads are new comparing thread dumps which are in archived artifact created by job [1]. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. check number of threads before reloading, during reload and after reload and see the differences (you need to wait for some time allowing to stabilize the number of threads after reload), ideally used the job [1] which does exactly that Actual results: number of threads increased Expected results: number of threads should remain the same [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-WS/job/eap-6.x-count-of-open-files/jdk=jdk1.6.unlimited.BC,label=RHEL6/17/console
the reproduction steps are simple: 1) start eap, take several measurements of threads and create thread dumps for comparison 2) reload server via ./jboss-cli.sh -c reload * again check threads using thread dump 3) after some time it becomes stable amount of threads, which you can compare with threads before reload The results are available in [1], also uploading it as attachment to this BZ PS: first I have sent https link, sorry for that, sending http link now [1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-WS/job/eap-6.x-count-of-open-files/17/jdk=jdk1.6.unlimited.BC,label=RHEL6/artifact/archive.zip
Created attachment 878116 [details] thread dumps before, during and after reload including server log
I have looked at the thread dumps, specifically before-1, before-10 and after-10 and I don't see anything unexpected. The "after-10" dump shows the following, which are not in the "before" dump: "Remoting "vmg38:MANAGEMENT" task-1" prio=10 tid=0x00007fb1e4110800 nid=0x6ced waiting on condition [0x00007fb215927000] "Remoting "vmg38:MANAGEMENT" task-2" prio=10 tid=0x00007fb1e4115000 nid=0x6cee waiting on condition [0x00007fb1e0bca000] "Remoting "vmg38:MANAGEMENT" task-3" prio=10 tid=0x00007fb1e4100800 nid=0x6cef waiting on condition [0x00007fb1e0ac9000] "Remoting "vmg38:MANAGEMENT" task-4" prio=10 tid=0x00007fb1e404a000 nid=0x6cf0 waiting on condition [0x00007fb1e09c8000] Those are not problematic unless they are growing over time beyond 4 threads. They are threads in a pool with a core size of 4 and an idle timeout for non-core threads of 60 secs. The threads appear when the management endpoint needs them to handle requests, so they are not there in a post-boot thread dump. Only if the count grows past 4 and does not shrink back down to 4 after 60 secs, is there a problem. Please identify what you believe is a thread leak, showing how it leaks over time, or please close this issue as NOT A BUG. Thanks!
Ok, from your explanation I also think this is not a bug. Petr, please if you agree close this bug.
Closing based on comment#4 (@Brian thank you for explanation)