shevchik / udpserversocketchannel Goto Github PK

As per the recommended approach mentioned to run time-consuming task in https://netty.io/4.1/api/io/netty/channel/ChannelPipeline.html, I tried the following in a project which uses this library:

Approach 1

static final EventExecutorGroup group = new DefaultEventExecutorGroup(16);
....
 ChannelPipeline pipeline = ch.pipeline();
 pipeline.addLast("decoder", new MyProtocolDecoder());
 pipeline.addLast("encoder", new MyProtocolEncoder());
pipeline.addLast(group, "handler", new MyBusinessLogicHandler());

This worked well when I execute JMeter script generating 50-100 requests. But, I had used the following to bootstrap UDP Server:

EventLoopGroup bossGroup = new NioEventLoopGroup();
EventLoopGroup workerGroup = new NioEventLoopGroup();
        try {
            ServerBootstrap serverBootstrap = new ServerBootstrap();
            serverBootstrap.group(bossGroup, workerGroup);

As per #7 (comment), the recommended approach is to use DefaultEventLoopGroup instead of NioEventLoopGroup "because user worker threads don't do any native socket/reading writing, they only process user tasks and pipeline operations."

So, I made the following change as per the example (ExampleUdpServer.java) in my project:

Approach 2

EventLoopGroup **workerGroup** = new DefaultEventLoopGroup();
try {
            ServerBootstrap serverBootstrap = new ServerBootstrap();
            serverBootstrap.group(workerGroup);

The Channel pipeline code remains same as Approach 1:

static final EventExecutorGroup group = new DefaultEventExecutorGroup(16);
....
 ChannelPipeline pipeline = ch.pipeline();
 pipeline.addLast("decoder", new MyProtocolDecoder());
 pipeline.addLast("encoder", new MyProtocolEncoder());
pipeline.addLast(group, "handler", new MyBusinessLogicHandler());

But, with this change, several requests are failing when I execute JMeter script. I further made a change to use the same DefaultEventLoopGroup to execute long running tasks:

Approach 3

int noOfWorkerThreads = 16;
EventLoopGroup **workerGroup** = new DefaultEventLoopGroup(noOfWorkerThreads);
        try {
            ServerBootstrap serverBootstrap = new ServerBootstrap();
            serverBootstrap.group(workerGroup);

        pipeline.addLast(**workerGroup**, "handler", new MyBusinessLogicHandler());

This also worked well when I execute JMeter script generating 50-100 requests. But, here I am using DefaultEventLoopGroup instead of the recommended DefaultEventExecutorGroup to run time-consuming task.

I would have expected Approach 2 to work which is the correct approach in my understanding. Could you please provide your inputs?

Support for 4.1 would be really helpfull - I ported it myself, but after changes from #1 I'd better stick with 4.0 for now.

Currently io server channel forces client read without checking isAutoRead().

Please consider adding some JUnit test for your project. This will require some gradle tweaking to make it work, as your current structure is not 'typical' :)

I've actually added a failing test here darkwitch@fde64fb

Hi,

I've just detected a nasty bug, when every once in a while we get a partial data in channelRead0.

I've forked your project and created a failing JUnit test for that here darkwitch@fde64fb.

Attached is a modified version of the test that will run out of the box, so that you do not have to change your project. It requires java8 however.

IncorrectFrameReceivedTest.java.txt

I'm using your UdpServerSocketChannel in my project, but I notice very high cpu load after starting the application on both Windows and Linux (Ubuntu 16.04).

Minimal code required to reproduce: your ExampleUdpServer

When you lunch it this is what happens (both when app is just lunched waiting for connections and after few connections were made):

Which is caused by the nioEventLoopGroup thread pool:

In general the application is producing lots of ArrayList.Iterator :) and GC is taking lot's of cpu time to clean it up.

I've traced it to selector.select(timeoutMillis) call of netty 4.0.30.Final (NioEventLoop:622)

In my opinion this should block until new operation is ready for the DatagramChannel, but in case of netty and your plugin this doesn't happen.

Here's a non-netty sample where this behaves correctly - might be usefull.
http://thushw.blogspot.com/2011/06/asynchronous-udp-server-using-java-nio.html

I've modified your code to make it compatible with netty 4.1.1.Final - but the problem persists.
This doesn't happen when using netty with TCP.

Your code works great! I have the same case: UDP and private Channel for each client.
But, I'm not sure about somethings:

1. The parameter 'ioThreads'.
2. ServerBootstrap.group(new DefaultEventLoopGroup()), but not the ServerBootstrap.group(new NioEventLoopGroup(), new NioEventLoopGroup()).

So, could you please say more details?
Thanks.

There is a requirement in my project to obtain Host Address of the sender from the UDP Header for processing the request. As per my understanding, I need to add a handler using which I will get DatagramPacket. So, I modified the usage example given in https://github.com/Shevchik/UdpServerSocketChannel by replacing:
private static class Echo extends SimpleChannelInboundHandler
with
public static class Echo extends SimpleChannelInboundHandler.

The modified example is attached.

But, protected void channelRead0(ChannelHandlerContext channelHandlerContext, DatagramPacket datagramPacket) throws Exception is not invoked at all. It may be because the library (UdpServerSocketChannel) already has a similar handler

Can you please let me know if the above solution which I am trying can be made to work? If not, please let me know any alternate solution which I can try.

Thanks!

ExampleUdpServer.txt