-
Bug
-
Resolution: Obsolete
-
Major
-
None
-
7.2.8.GA
-
None
Every so often, and for no clear reason, a few threads running in the application server start using 100% CPU. When this happens, removing all load from the application server does not relieve the problem – the same threads continue to use 100% CPU. All these threads originate from the httpcore-nio JAR, and mostly look like this:
"I/O dispatcher 39" #885 prio=5 os_prio=0 tid=0x00000000093ae000 nid=0x6245 runnable [0x00007f0d5267a000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) - locked <0x0000000519e671a8> (a sun.nio.ch.Util$3) - locked <0x0000000519e67198> (a java.util.Collections$UnmodifiableSet) - locked <0x0000000519e67150> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:255) at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) at java.lang.Thread.run(Thread.java:748)
However, with extended monitoring, we see that these threads sometimes do something else for a short time, before reverting to the pattern above.
This problem has been noticed after an upgrade from EAP 7.1. The application uses CXF, although that isn't obvious in the thread stacks.
- relates to
-
-
- Closed
-
