Netty 4.0.17.Final released
We are happy to announce the release of Netty 4.0.17.Final. This release again fixes a lot of bugs together with 4.0.16.Final and also two regressions introduced in 4.0.16.Final (this is why 4.0.16.Final was not announced).
Beside this it also introduce a new native transport which is based on epoll edge-triggered (using C / JNI) for maximal performance and low latency. Release 4.0.17.Final and 4.0.16.Final fixes 45 issues/tasks/improvements in summary.
So you should consider upgrading if you are using an early release. As always this release is backwards-compatible with earlier releases of the 4.0.x series.
Most important changes / fixes
- Introduce a native transport for linux using epoll ET (#2229)
- Web Socket server leaks a buffer during a handshake (#2188)
- Race condition in AbstractReferenceCountedByteBuf and AbstractReferenceCounted (#2187)
- Allow to cancel non-flushed writes (#2214) and (#2209)
- Race in DefaultPromise which could lead to out of order notification of listeners (#2186) and (#2157)
- Fix for releasing of the internal cumulation buffer in ByteToMessageDecoder (#2184)
- Server sending websocket frame too quickly after upgrade causes client disconnect (#2173)
- Not wakeup the EventLoop for writes as they will not cause a flush anyway (#2172)
- Not throw an exception if WS subprotocol is not supported but just drop the header as stated in the RFC's (#2149)
- Calling Channel.read() within channelReadComplete() not works when AutoRead is false (#2254)
Visit here and here for the complete list of the changes.
As always please let us know if you find any issues. We love feedback!
Special notes
Native epoll edge-triggered transport
This release features a new native epoll based transport that uses edge-triggered mode for maximal performance and low latency. This transport only works on Linux (as this is the OS which uses epoll), so if you not use Linux you can stop reading here ;)
The transport is part of the netty-transport-native-epoll artifact but is also included in netty-all. To make use of it just configure the Bootstrap
or ServerBootstrap
as usual but provide the specific Channel
and EventLoopGroup
.
For any example refer to the next code snipped.
EventLoopGroup group = new EpollEventLoopGroup();
try {
ServerBootstrap b = new ServerBootstrap();
b.group(group)
.childHandler(new YourInitializer())
.channel(EpollServerSocketChannel.class);
Channel ch = b.bind(port).sync().channel();
ch.closeFuture().sync();
} finally {
group.shutdownGracefully().sync();
}
Beside the usual ChannelOption
s the Native Transport allows to enable TCP_CORK which may come in handy if you implement a HTTP Server.
Be aware this transport only includes SocketChannel
and ServerSocketChannel implementations at the moment and so can only be used for TCP. This may change in the future. Also note while the transport pass all our Unit Tests and works in our benchmark there may be still issues that need to get fixed, so this transport is still considered somewhat experimental. But if you are brave enough to try please provide feedback :)
Thank You
Every idea and bug-report counts and so we thought it is worth mentioning those who helped in this area. Please report an unintended omission.