[
https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi...
]
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/...
{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)