[
https://issues.apache.org/jira/browse/DIRMINA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117750#comment-15117750
]
Emmanuel Lecharny commented on DIRMINA-1006:
--------------------------------------------
Dang...
The {{wakeupCalled}} should be reset to {{false}} when it was the reason the
{{select()}} was interrupted...
And in this case, if we are hit by the nasty spinning bug, then we don't take
the chance to create a new selector because the flag is not false :/
The code should probably be :
{noformat}
if (wakeupCalled.get()) {
wakeupCalled.getAndSet(false);
// We have been waked up, the processing will continue
} else if ((selected == 0) && (delta < 100)) {
// Last chance : the select() may have been
// interrupted because we have had an closed channel.
if (isBrokenConnection()) {
LOG.warn("Broken connection");
} else {
LOG.warn("Create a new selector. Selected is 0,
delta = " + (t1 - t0));
// Ok, we are hit by the nasty epoll
// spinning.
// Basically, there is a race condition
// which causes a closing file descriptor not to be
// considered as available as a selected channel,
// but
// it stopped the select. The next time we will
// call select(), it will exit immediately for the
// same
// reason, and do so forever, consuming 100%
// CPU.
// We have to destroy the selector, and
// register all the socket on a new one.
registerNewSelector();
}
// and continue the loop
continue;
}
{noformat}
> mina2.0.9 NioProcessor thread make cpu 100%
> -------------------------------------------
>
> Key: DIRMINA-1006
> URL: https://issues.apache.org/jira/browse/DIRMINA-1006
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.9
> Environment: Linux version 2.6.32-358.el6.x86_64 (Red Hat 4.4.7-3)
> java version "1.7.0_67"
> Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> Reporter: briokyd
> Priority: Blocker
> Attachments: cpu100_01.png, cpu100_02.png, cpu100_03.png,
> threadDump78658_20150211_151742.log
>
>
> running as client after the Exception (java.io.IOException: Connection reset
> by peer) appeared , cpu 100%
> thread dump:
> "NioProcessor-931" prio=10 tid=0x00007f3788004800 nid=0xd41 runnable
> [0x00007f394f4f3000]
> 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:79)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
> - locked <0x00000007842118f0> (a sun.nio.ch.Util$2)
> - locked <0x00000007842118e0> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000007842114b0> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:97)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1074)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Locked ownable synchronizers:
> - <0x0000000784211210> (a
> java.util.concurrent.ThreadPoolExecutor$Worker)
> is that nio epollWait bug?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
