]
Brian Stansberry moved JBEAP-4546 to WFCORE-1529:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1529 (was: JBEAP-4546)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 2.1.0.Final
(was: 7.0.0.CR2)
New threads named ServerService Thread Pool -- xyz created with every
deploy and undeploy and removed after ~20 seconds
-----------------------------------------------------------------------------------------------------------------------
Key: WFCORE-1529
URL:
https://issues.jboss.org/browse/WFCORE-1529
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.1.0.Final
Reporter: Rostislav Svoboda
Assignee: Brian Stansberry
I did quite simple thing in the loop :
* deploy attached application into jboss-eap-7.0/standalone/deployments/
* wait 1 minute
* remove anything from jboss-eap-7.0/standalone/deployments/
* wait 1 minute
I connected with jvisualvm and was watching monitor tab for cpu / classes / heap /
threads overview statistics. After some time I spotted jumps (up and down) on threads.
After some time I see threads named "ServerService Thread Pool -- 346", I ended
with number bigger than 1400. In my case 15 threads are created for 20 seconds when
deploying and another 15 threads are created for 20 seconds when undeploying. Nothing
seems to be reused
Setup for threads is done in
https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
method addService
Is it intentional to have threads alive only 20 seconds and then scratch them ? Keeping a
lot of threads means usage of system resources, creating new threads has some overhead
too. Maybe the question is what is the right balance ?
Note: It would be nice to have "Possible Bug" Issue Type for issues like this
;)