[ 
https://issues.apache.org/jira/browse/DIRMINA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118307#comment-15118307
 ] 

Emmanuel Lecharny commented on DIRMINA-1006:
--------------------------------------------

The scenario where you have a 100% CPU is :
- {{select()}} must return 0 (quite rare)
- the {{wakeupCalled}} must been 'true', ie the {{select()}} was waken up by an 
explicit call to the {{wakeup()}} method

As we don't reset the flag in this case, we loop.

There is another bug : 

In the original code, we don't reset the flag immediately, so it's possible 
that we enter into the {{if}} with a value of {{false}} for the flag which get 
flip to {{true}} by a call to {{wakeup()}} just before we recreate a new 
selector. In this case, we will not process the remaining elements, and it's 
bad.

Bottom line, when we check the {{wakeupCalled}}, we also have to reset it in 
the same atomic operation.

> 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)

Reply via email to