Upgrade to Netty 4.0

I'm currently working on this. Writing the issue here so we could discuss.

Netty 4 is not yet stable, so I won't merge until everything is tested and Netty 4 has a stable release.

[kimchy]

cool, btw, I have been looking into this as well, its quite a bit of work, might request some changes in other parts of ES to properly use the new buffering model (that I still need to fully understand how its implemented).

I haven't looked into how exactly it's implemented, but the API is the same in that regard (other than changing the name from ChannelBuffer to ByteBuf). The ChannelBuffer class was only used in a few pieces, namely to support the HTTP server. Other than that, it's very modular, and swapping out the HTTP servers should be fairly trivial.

What's NOT trivial is that the API is very much streamlined in 4.0, whereas it's not so much in 3.6. I'm spending quite a bit of time trying to decipher the logic in 3.6, but very little time actually translating it to 4.0 once understood.

For your reference, these were the packages impacted:

org.elasticsearch.bulk.udp
org.elasticsearch.common.byte
org.elasticsearch.common.compress
org.elasticsearch.common.compress.lzf
org.elasticsearch.common.netty
org.elasticsearch.common.http.netty
org.elasticsearch.transport.netty

The byte and compress packages were only slightly modified to act as utilities for the other packages. the org.elasticsearch.common.http package was completely generic. I think someone had the foresight to believe that the HTTP functionality would eventually be swapped. org.elasticsearch.common.netty were basically utility functions for the other packages.

The hardest to change will be org.elasticsearch.common.http.netty and org.elasticsearch.transport.netty, which is what I'm up to right now. I won't be able to test until I can resolve the dependencies, so the most time consuming part will be testing and refactoring.

In all, it's a real challenge. But I'm down :)

I'm actually mainly doing this so I can hopefully build in Websocket support. I want to be able to stream searches ;)

-Cris

[spinscale]

Hey,

there was just a post about a major refactoring from one netty 4 CR to another CR version. See http://netty.io/news/2013/06/18/4-0-0-CR5.html

Just wanted to ensure, that one cannot be totally confident, that this is the last breaking netty 4 change by the netty team (which I like personally, as performance is a first class citizen here).

--Alex

Thanks for the heads up! I've been on their IRC, but I don't think I've managed to talk with anyone on their team (or at least I'm not sure :) ). Right now, I'm working off of their current branch, so this is actually 4.0.0-CR7-SNAPSHOT. I am expecting it to change, but I figured now would be a good time to at least start. It's drastic enough from 3.6 that I think going from 4.0.0-CR7 to release would be easier.

Also I want this done for my own uses sooner than waiting :)

[kimchy]

The way I saw it, to properly use the new netty 4 features, we will need to make use of the new buffering mechanisms to reduce buffer copies. Currently, we heavily rely on how buffers are handled in netty 3 in the IO reader and writer threads, which we will probably need to properly understand to use with netty 4. I think (haven't looked closely) that we will need to change things like how REST actions serialize data to make sure we reduce buffer copies.

I've just been replacing the data types with the Netty 4 equivalents, but I'm at the point where I have to rewrite the pipelining. I'll go back and take a look at buffering, because I didn't exactly take a close look under the hood.

[icedfish]

Hi all,
Netty 4.0 Stable has been released :
https://github.com/netty/netty/releases/tag/netty-4.0.0.Final

I'll take a look again soon.

[GrantGochnauer]

+1 - http://www.infoq.com/news/2013/11/netty4-twitter

[kimchy]

I had another look, and I am not too happy with some of the netty 4 behavior.Note, the behavior people see (less GC) happens with "stock" netty, we do quite a few tricky to reduce the buffer copies already. The migration will require quite a bit of work in order to maintain those optimizations... (we will do it anyhow). Also need to find the time to raise some of the issues with netty...

[GrantGochnauer]

Thanks for the update Shay!

[normanmaurer]

@kimchy what "issues" you are talking about? Maybe I can give you some pointers.

[kimchy]

@normanmaurer I will start respective questions properly on the netty mailing list.

[normanmaurer]

@kimchy alright..

[kimchy]

@normanmaurer cool, we are focused on getting a new version of ES out, so not focusing on netty 4 now, especially with the problematic aspects I saw there and the fact that it will be a bigger change than expected. And trust me, the "issues" there should not have quotation marks as in your comment, we use it in quite an advance manner make sure we don't allocate buffers needlessly, and the refactoring done in netty 4 is, well, tricky.... (admittedly, it does help naive handlers).