[
https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi...
]
Masafumi Miura commented on WFCORE-1934:
----------------------------------------
Yes, it's not semantically equivalent to the default behavior...
As far as I read the API documentation of
[
ThreadPoolExecutor|https://docs.oracle.com/javase/8/docs/api/java/util/co...],
there's three options for thread queuing strategies:
1. An unlimited size pool with direct handoffs (SynchronousQueue)
2. A fixed finite size pool with an unbounded queue (LinkedBlockingQueue)
3. A finite max size pool with a bounded queue (ArrayBlockingQueue)
(Or a finite max size pool with direct handoffs. but this would be undesirable option.)
If I understand correctly, a strategy of the current implementation is option 1. And I
thought it's hard to controll how many tasks are executed concurrently, so I thought
option 2 (a fixed size pool with an unbounded queue) is better than others when we added a
upper limit for the number of the thread pool. (We would face RejectedExecutionException
when tasks overflows max pool size and queue, if we select option 3 (or a finite max size
pool with direct handoffs)).
Please feel free to point out if I'm misunderstand anything. Also please suggest a
better idea for this if you agree to add a upper limit for the number of this thread
pool.
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)