Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
NIO.2 support #2515
I saw that Netty.4.Final dropped support for AIO. In the book "Netty in Action" I read that it was dropped mainly because it was not faster and that netty's threading model would make it hard to interoperate, which makes sense.
But maybe I could provide another view, since I'm heavily interested in windows support:
The NIO.1 Selector works using kqueue, epoll and select on pretty much all platforms. Now Windows does have IOCP which is way better than select (select on windows have scalability issues). But, of course, IOCP is the proactor model and does not fit in the reactor-selector-pattern.
That's why JDK7 finally brought us AIO, which implements the proactor pattern. The good thing about the proactor pattern is that it abstract's both select-based-techniques and IOCP very well.
What this all means is, that NIO.1 (Netty =( ) on windows simply does not scale as good as it could be.
I do understand the technical consequences of AIO for netty, though. AIO does have limitations, too.
I know that this means some work and I am willing to contribute, but I would like to hear your point of view, maybe I do not have enough knowledge about this topic ;=)
We obviously did not consider Windows as a serious platform so far, and that's why we were neglecting NIO.2 AIO API which was implemented using IOCP on Windows. (On Linux, it wasn't any faster because it was using the same OS facility - epoll.)
There are two ways to implement your idea:
If you are proficient with Win32/C programming, I would recommend the second approach because there's not much point in having another layer of abstraction (NIO.2). As demonstrated by netty-transport-native-epoll, removing an abstraction layer between Netty and OS yields better performance.
It you are inclined to the first solution, you could check out some old pre-release Netty version which ships the AIO transport and start from there. In this case, I would be interested to compare the performance between the NIO transport and the AIO transport on Windows before merging it.
Great, I will look into this issue the next weekend. Your point about native vs NIO-abstractions is definitely something I will consider. I will start with NIO.2 and check if it's worth it.
Some stuff I saw so far in the sun.nio.ch.WindowsSelectorImpl:
54 // Should be INIT_CAP times a power of 2
69 // Number of helper threads needed for select. We need one thread per
As you can see every 1024 sockets the select implementation will use a new thread, which is not that bad but because select is O(n) and especially bad on windows NIO.2 should bring a noticeable improvement. The bad thing about it is that I can not really benchmark it since I have only a dated windows laptop. I mainly work on OSX but windows is important for me nonetheless.
I found some time today to investigate the AIO implementation of Netty.4.0.0.CR3.
It's basically exactly what I was thinking of. The custom implementation of AioEventLoop should be fine, since every continuation is scheduled in one thread - the event loop thread. No useless context switches =).
The AioSocketChannel was a bit complicated but I think I got it now. After all I will test this implementation this evening or probably tomorrow on a windows network against the select version in terms of latency and CPU overhead (posix-select could eventually drive the cpu crazy on windows systems).
But my guess is that the AIO impl. will perform quite well. If this is the case I would kindly ask to take the AIO implementation back into master-branch =). I think it makes not much sense to write another AIO implementation if the existing one is already quite sophisticated ;=).
Or let's put it this way: What disadvantages would you see to support AIO ? I mean, of course, it adds maintenance costs which might or might not be worth it.
According to the book the main reasons were:
I agree that AIO will not easily replace NIO, but it is useful for windows developers nonetheless.
These are my thoughts so far
Sounds good... Thanks!
Unfortunately I did not get access to the windows network, the admin was against it, as always 8-|
I told him the fact that windows-select is crappy and he told me that this is not true anymore for Win7 & 8, which was really interesting for me. He said that it was actually very true for XP (probably even Vista), but since 7 the network stack got an update, which was new to me. IOCP still has some advantages but selector based networks are definitely capable of handling a lot of throughput since Win7, which is nice =).
I do not have any numbers but the project lead is happy with this now and so my priorities have changed, so for me this issue is kind if closed.