[
https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi...
]
Masafumi Miura commented on WFCORE-1934:
----------------------------------------
Here's a proposed patch:
https://github.com/wildfly/wildfly-core/compare/2.x...msfm:WFCORE-1934
I would like to propose a new system property {{org.jboss.server.services.maxThreads}} for
ServerService Thread Pool (similarly to org.jboss.server.bootstrap.maxThreads for MSC
Threads).
Default is not changed. But, when {{org.jboss.server.services.maxThreads}} is configured,
the specified value is set to both corePoolSize and maximumPoolSize, and also
BlockingQueue is changed from SynchronousQueue (Direct handoffs) to LinkedBlockingQueue
(Unbounded queues):
|| || corePoolSize || maximumPoolSize || BlockingQueue ||
|Default| 0 | Integer.MAX_VALUE | SynchronousQueue |
|-Dorg.jboss.server.services.maxThreads=100 | 100 | 100 | LinkedBlockingQueue |
Make maximumPoolSize of ServerService Thread Pool configurable
--------------------------------------------------------------
Key: WFCORE-1934
URL:
https://issues.jboss.org/browse/WFCORE-1934
Project: WildFly Core
Issue Type: Bug
Components: Server
Affects Versions: 2.2.0.Final
Reporter: Masafumi Miura
Assignee: Jason Greene
Attachments: ServerServiceThreadPool_ejb_startup_singleton.zip,
ServerServiceThreadPool_persistence_unit.zip
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)