[jboss-jira] [JBoss JIRA] (WFCORE-1934) Make maximumPoolSize of ServerService Thread Pool configurable

[Masafumi Miura (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13318405#comment-13318405 ] 

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/concurrent/ThreadPoolExecutor.html], 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/org/jboss/as/server/ServerService.java#L446-L449
> {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)