mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DIRMINA-1006) mina2.0.9 NioProcessor thread make cpu 100%
Date Wed, 27 Jan 2016 10:13:40 GMT

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

Emmanuel Lecharny edited comment on DIRMINA-1006 at 1/27/16 10:12 AM:
----------------------------------------------------------------------

I changed the order in the test, so that the flag is flip to {{false}} no matter what, and
I removed the {{continue}}. The reason is that we *need* this flag to be flip to {{false}}
if it was {{true}}, regardless of the potential spin bug. 

Hes, the call to {{wakepup()}} when we are disposing the selector is mandatory, because we
need to process the sessions that have been put into the {{removingSessions}} queue, something
that is done by a call to the {{removeSessions()}} method higher (line 1094).

This piece of code is convoluted, and needs some love. 

Here is the latest version :

{noformat}
            for (;;) {
                try {
                    // This select has a timeout so that we can manage
                    // idle session when we get out of the select every
                    // second. (note : this is a hack to avoid creating
                    // a dedicated thread).
                    long t0 = System.currentTimeMillis();
                    int selected = select(SELECT_TIMEOUT);
                    long t1 = System.currentTimeMillis();
                    long delta = (t1 - t0);

                    if (!wakeupCalled.getAndSet(false) && (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();
                        }
                    }
...
{noformat}


was (Author: elecharny):
I changed the order in the test, so that the flag is flip to {{false}} no matter what, and
I removed the {{continue}}. The reason is that we *need* this flag to be flip to {{false}}
if it was {{true}}, regardless of the potential spin bug. 

Hes, the call to {{wakepup()}} when we are disposing the selector is mandatory, because we
need to process the sessions that have been put into the {{removingSessions}} queue, something
that is done by a call to the {{removeSessions()}} method higher (line 1094).

This piece of code is convoluted, and needs some love. 

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

Mime
View raw message