JBOSS Wildfly10 use CPU 100%

[macber]

Hello everybody,

I've updated the version of JBOSS 6.1 to Wildfly10, and I'm having problems with CPU usage. After debug and investigating I have seen that it is exactly the same case as described on.

[Solved] Wildfly 8 Final - 100% cpu usage, no load, either due to Undertow's ServletPriterWriter or NIO CharsetEncoder

Has anyone else occurred to you?

Regards and Thanks!

[ctomc]

OS, JDK, thread dump?

profiling output?

[macber]

Sorry, my configuration is:

- S.O. Windows 7 64 bit

- CPU 4 cores

- RAM 8GB

- JDK 1.8.0_92 64 bit

- Server JBOSS Wildfly 10.0.0 Final

- Memory for JBOSS: -Xms4096M -Xmx4096M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=512M

JMC capture:

Thread dump:

"default task-6" #1090 prio=5 os_prio=0 tid=0x0000000034622000 nid=0x24e8 runnable [0x00000000222ce000]
   java.lang.Thread.State: RUNNABLE
at io.undertow.servlet.spec.ServletOutputStreamImpl.underlyingBuffer(ServletOutputStreamImpl.java:448)
at io.undertow.servlet.spec.ServletPrintWriter.close(ServletPrintWriter.java:98)
at io.undertow.servlet.spec.ServletPrintWriterDelegate.close(ServletPrintWriterDelegate.java:99)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:470)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:560)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
- <0x00000006f2a7fbb8> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"default task-15" #1099 prio=5 os_prio=0 tid=0x0000000034629000 nid=0x2794 runnable [0x000000002e1fe000]
   java.lang.Thread.State: RUNNABLE
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
at io.undertow.servlet.spec.ServletOutputStreamImpl.flushInternal(ServletOutputStreamImpl.java:487)
at io.undertow.servlet.spec.ServletPrintWriter.close(ServletPrintWriter.java:106)
at io.undertow.servlet.spec.ServletPrintWriterDelegate.close(ServletPrintWriterDelegate.java:99)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:470)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:560)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
- <0x00000006f2a78eb8> (a java.util.concurrent.ThreadPoolExecutor$Worker)

In this case there are 2 threads that use 50% of the total CPU. It seems that this problem occurs more frequently with ajax requests.

[jaikiran]

- Server JBOSS Wildfly 10.0.0 Final

Can you please give the latest released WildFly 10.1.0.Final and see if it's still reproducible on that version? If it is, then someone can then look at figuring out the issue.

[macber]

Ok, I've tested Wildfly version 10.1.0, but the problem keeps happening.

Debugging the code I have also seen that an infinite loop occurs in the method io.undertow.servlet.spec.ServletPrintWriter.close()

[jaikiran]

Thanks for testing against 10.1.0.Final. Would it be possible to attach a simple application which reproduces this issue? Furthermore, what locale is the JVM of the WildFly server, running under?