[ https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi... ] Masafumi Miura updated WFCORE-1934: ----------------------------------- Description: Provide a way to configure {{maximumPoolSize}} of {{ServerService Thread Pool}}. It defaults to {{Integer.MAX_VALUE}} and it's unable to be changed in the current implementation: {quote} https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... {code} 446 public synchronized void start(StartContext context) throws StartException { 447 executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 20L, TimeUnit.SECONDS, 448 new SynchronousQueue<Runnable>(), threadFactory); 449 } {code} {quote} Though the threads will disappear after 20 seconds of finishing a task, ulimit ({{nproc}}, max user processes) has a possibility to run out and "java.lang.OutOfMemoryError: unable to create new native thread" would occur depending on deployed applications. For example, an application coming with many {{<persistence-unit>}} entries in {{persistence.xml}} or a lot of @Startup @Singleton EJB can cause spawning a lot of {{ServerService Thread Pool}} thread. Even if ulimit can be configurable and it is recommended to be tuned in a production environment, making {{maximumPoolSize}} of {{ServerService Thread Pool}} configurable would be helpful. was: Provide a way to configure {{maximumPoolSize}} of {{ServerService Thread Pool}}. It defaults to {{Integer.MAX_VALUE}} and it's unable to be changed in the current implementation: {quote} https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... {code} 446 public synchronized void start(StartContext context) throws StartException { 447 executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 20L, TimeUnit.SECONDS, 448 new SynchronousQueue<Runnable>(), threadFactory); 449 } {code} {quote} Though the threads will disappear after 20 seconds of finishing a task, ulimit ({{nproc}}, max user processes) has a possibility to run out depending on deployed applications. For example, an application coming with many {{<persistence-unit>}} entries in {{persistence.xml}} or a lot of @Startup @Singleton EJB can cause spawning a lot of {{ServerService Thread Pool}} thread. Even if ulimit can be configurable and it is recommended to be tuned in a production environment, making {{maximumPoolSize}} of {{ServerService Thread Pool}} configurable would be helpful. -- This message was sent by Atlassian JIRA (v7.2.3#72005)