High CPU in TempFileProviderService thread

Environment

• JBoss Enterprise Application Platform (EAP) 6.x
• Java 8 and earlier

Issue

• We see high CPU in a TempFileProviderService thread, for example:

"TempFileProviderService-temp-threads - 1" #103 daemon prio=5 os_prio=0 tid=0x00007f01bc0bc800 nid=0x3e78 runnable [0x00007f01887b3000]
   java.lang.Thread.State: RUNNABLE
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
        at org.jboss.threads.JBossThread.run(JBossThread.java:122)

Resolution

• Await a fix to come in EAP 6.4 CP

Root Cause

• This occurs due to a Content from bugs.openjdk.java.net is not included.flaw in the JDK's ThreadPoolExecutor implementation. This flaw allows for circular logic for a 0 core pool size ScheduledThreadPoolExecutor because when it sees more than core threads, it decides to poll the queue (with a 0 time by default), but it only allows for a thread to be killed after that queue poll if core threads is greater than 1 when the queue is not empty. So if the ScheduledThreadPoolExecutor's queue is not empty, then you will end up with a single thread that continuously loops over queue polls in a high CPU loop until the queue is potentially empty again.
• Content from issues.jboss.org is not included.WFCORE-1093
• This content is not included.BZ-1277699

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.