tl;dr version from Brian:

The ServerService Threads and Host Controller Service Threads pools have no core size and a thread timeout of 20 secs, so if a management request comes in periodically but less often then every 20 secs (says twice a minute) the pool will continually churn threads. That kind of periodic polling is not an unusual scenario, so, we'll put in a core size of one or two.

Original details from Rostislav:

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/org/jboss/as/server/ServerService.java#L207-L213 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