[
https://issues.apache.org/jira/browse/DIRMINA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019812#comment-13019812
]
Emmanuel Lecharny commented on DIRMINA-678:
-------------------------------------------
No. I suppose that the bug has been fixed (many people told me that it has been
fixed), and incidentally the workaround has been removed in MINA 2.0.2.
The problem is that many people out there are still using older JVM, and the
workaround is really costing nothing, so it was a better idea to keep it around.
FYI, the problem was that the select() method could return immediately, but
with a 0 value, in some specific cases. Sadly, in this case, we just loop and
do a select() again, which returns 0 immediately, etc (so the 100% CPU). The
workaround was to compute the time we spent on the select(), and if under
100ms, when it returns 0, we consider that the selector is FU, so we kill it,
create a new one, and copy all the selectionKeys in the new selector.
> NioProcessor 100% CPU usage on Linux (epoll selector bug)
> ---------------------------------------------------------
>
> Key: DIRMINA-678
> URL: https://issues.apache.org/jira/browse/DIRMINA-678
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.0-M4
> Environment: CentOS 5.x, 32/64-bit, 32/64-bit Sun JDK 1.6.0_12, also
> _11/_10/_09 and Sun JDK 1.7.0 b50, Kernel 2.6.18-92.1.22.el5 and also older
> versions,
> Reporter: Serge Baranov
> Fix For: 2.0.3
>
> Attachments: mina-2.0.3.diff, snap973.png, snap974.png
>
>
> It's the same bug as described at http://jira.codehaus.org/browse/JETTY-937 ,
> but affecting MINA in the very similar way.
> NioProcessor threads start to eat 100% resources per CPU. After 10-30 minutes
> of running depending on the load (sometimes after several hours) one of the
> NioProcessor starts to consume all the available CPU resources probably
> spinning in the epoll select loop. Later, more threads can be affected by the
> same issue, thus 100% loading all the available CPU cores.
> Sample trace:
> NioProcessor-10 [RUNNABLE] CPU time: 5:15
> sun.nio.ch.EPollArrayWrapper.epollWait(long, int, long, int)
> sun.nio.ch.EPollArrayWrapper.poll(long)
> sun.nio.ch.EPollSelectorImpl.doSelect(long)
> sun.nio.ch.SelectorImpl.lockAndDoSelect(long)
> sun.nio.ch.SelectorImpl.select(long)
> org.apache.mina.transport.socket.nio.NioProcessor.select(long)
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run()
> org.apache.mina.util.NamePreservingRunnable.run()
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> java.util.concurrent.ThreadPoolExecutor$Worker.run()
> java.lang.Thread.run()
> It seems to affect any NIO based Java server applications running in the
> specified environment.
> Some projects provide workarounds for similar JDK bugs, probably MINA can
> also think about a workaround.
> As far as I know, there are at least 3 users who experience this issue with
> Jetty and all of them are running CentOS (some distribution default setting
> is a trigger?). As for MINA, I'm not aware of similar reports yet.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
