Bug 1079362
| Summary: | Reload operation increases number of threads used by server | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Radim Hatlapatka <rhatlapa> | ||||
| Component: | Domain Management | Assignee: | Brian Stansberry <brian.stansberry> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Petr Kremensky <pkremens> | ||||
| Severity: | high | Docs Contact: | Russell Dickenson <rdickens> | ||||
| Priority: | unspecified | ||||||
| Version: | 6.3.0 | CC: | emuckenh, psakar, rhatlapa | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-03-25 10:17:43 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Radim Hatlapatka
2014-03-21 13:29:41 UTC
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. |