[jboss-jira] [JBoss JIRA] (WFCORE-1093) TempFileProviderService threads consume high CPU

RH Bugzilla Integration (JIRA) issues at jboss.org
Fri Aug 5 01:50:00 EDT 2016


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

RH Bugzilla Integration commented on WFCORE-1093:
-------------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1277699|https://bugzilla.redhat.com/show_bug.cgi?id=1277699] from MODIFIED to ON_QA

> TempFileProviderService threads consume high CPU
> ------------------------------------------------
>
>                 Key: WFCORE-1093
>                 URL: https://issues.jboss.org/browse/WFCORE-1093
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Aaron Ogburn
>            Assignee: Jason Greene
>             Fix For: 2.0.3.Final
>
>
> TempFileProviderService threads consume high CPU as they poll their non empty task queue.  This is ultimately due to a flaw in the JDK ThreadPoolExecutor code (https://bugs.openjdk.java.net/browse/JDK-8129861), impacting ScheduledThreadPoolExecutors that use a core size of 0 and a default 0 keepalive timeout.  
> While the executor queue is not empty, the executor does not allow the pool to go below 1 thread.  So the one remaining work thread keeps looping over its poll call with a 0 timeout.  Options to protect JBoss from this are:
> 1) Set a keepalive timeout on the executor so the poll has a duration and the worker run loop isn't so busy
> 2) Or set the Executor core pool size to >0.  The worker thread would then use a blocking take() call on its queue instead of a constant 0 second poll calls.  The side effect of this change is that the thread pool wouldn't ever drop back down to 0.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


More information about the jboss-jira mailing list