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

Upgrade to Netty 4.0 #3226

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions