[jboss-jira] [JBoss JIRA] (WFCORE-1934) Make number of thread size for ServerService Thread Pool configurable

[Brian Stansberry (JIRA)]

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

Brian Stansberry commented on WFCORE-1934:
------------------------------------------

Option 2 is not a valid option, as tasks handed off to this queue must either be executed or the handoff must fail. The main uses of the pool count on this.

RejectedExecutionException is another form of failure, preferable in the abstract to an OOME, but a lot of uses of this method would need to be adapted to account for this possibility. And some of them I don't think really could be properly adapted.

I don't believe we should support making this configurable, as the end user is unlikely to know how to properly configure it. For scenarios like your reproducer, this is why you test things in staging -- to ensure that you have given your server adequate resources for the application you are deploying.

> Make number of thread size for 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 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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)