[#2426] Not cause busy loop when interrupt Thread of AbstractNioSelector

[normanmaurer]

Motivation:
Because Thread.currentThread().interrupt() will unblock Selector.select() we need to take special care when check if we need to rebuild the Selector. If the unblock was caused by the interrupt() we will clear it and move on as this is most likely a bug in a custom ChannelHandler or a library the user makes use of.

Modification:
Clear the interrupt state of the Thread if the Selector was unblock because of an interrupt and the returned keys was 0.

Result:
No more busy loop caused by Thread.currentThread().interrupt()

[normanmaurer]

@trustin please review... I would love to have this in all 3.6+ branches and 3.2 and cut a 3.6 and 3.2 release with it for Red Hat to consume .

[ghost]

Build result for #2868 at 908d815: Success

[ghost]

Build result for #2868 at 452e5ed: Success

[kylinsoong]

Thanks norman for your help, this saved us time.

[trustin]

' .. because the I/O thread has been interrupted. Use shutdown() to shut the NioSelector down.'

[trustin]

I proposed to rephrase the messages and comments. Besides that, it looks fine to me.

[trustin]

Once done, please feel free to merge.

[normanmaurer]

@trustin I will need to backport this to 3.6 and 3.2 also and cut a release. What else branches I should backport ?

[ghost]

Build result for #2868 at 0a374cd: Success

[trustin]

3.9? :-)

[normanmaurer]

@trustin ok 3.9 , 3.6 and .3.2 (sigh). Will cut a release for 3.6 and 3.2 ... Should I also do for 3.9 ?

[normanmaurer]

@trustin was wrong... only need 3.6 (not 3.2 :))

[trustin]

No need to release. I just meant this commit should go to the latest stable branches including 3.9. and what about 4.x and master? Are we affected there, either?

[normanmaurer]

No it is fixed already in master and 4.0

Am 12.09.2014 um 10:48 schrieb Trustin Lee notifications@github.com:

No need to release. I just meant this commit should go to the latest stable branches including 3.9. and what about 4.x and master? Are we affected there, either?

—
Reply to this email directly or view it on GitHub.

[normanmaurer]

Was merged into 3.6 and 3.9 branches.

[kylinsoong]

Today I debug teiid code(it use netty 3.6.2) find a easy way to reproduce high cpu in 3.6.2, if we run the following code:

        ExecutorService nettyPool = Executors.newCachedThreadPool();
        ChannelFactory factory = new NioServerSocketChannelFactory(nettyPool, nettyPool, 1);
        ServerBootstrap bootstrap = new ServerBootstrap(factory);
        bootstrap.setPipelineFactory(new ChannelPipelineFactory() {

            public ChannelPipeline getPipeline() throws Exception {
                return Channels.pipeline(new SimpleChannelHandler());
            }});
        bootstrap.setOption("keepAlive", Boolean.TRUE);
        Channel serverChanel = bootstrap.bind(new InetSocketAddress(0));

        serverChanel.close();
        nettyPool.shutdownNow();

        Thread.currentThread().sleep(Long.MAX_VALUE);

These code cause 2 threads(netty boss threads and netty worker threads) high cpu(100% cpu retained).

I also verified fixed version 3.6.10.Final(https://github.com/netty/netty/releases/tag/netty-3.6.10.Final), it fixed the issue.

I hope my founding can help others, http://ksoong.org/netty-highcpu/ have more details.