Skip navigation

Netty 4.2.0.Alpha1 released

by normanmaurer
on

We are happy to announce the release of the first alpha for the upcoming netty version 4.2.0. Everyone using netty 4.1.x should be able to upgrade to 4.2.0.Alpha1 without any API breakage. The only new requirement is JDK8 or later. This release has all the fixes that are also included in 4.1.111.Final.

We encourage users of netty 4.1.x to try out this alpha release and so provide feedback if any breakage is noticed. This will help us to be aware of any problems early in the release cycle. That said, be aware that this is only an alpha release and so shouldn't be considered for production usage.

Netty 4.2.0 will come with some exciting new features, two of which are already included in this first alpha release:

  • New way how EventLoopGroups are constructed (the old way is still preserved but marked as @deprecated)
  • io_uring based transport

For more details please visit our bug tracker

New Features

EventLoopGroup changes

In previous versions of netty the EventLoopGroup implementation was tightly coupled to the respective Channel implementation. This made it very hard to extend existing EventLoopGroups to add funcionality like instruments (especially because you might want to use different transports based on the platform you are running on).

This has changed in 4.2.0, here you will use one EventLoopGroup implementation for all transports. This allows for easier customization of it (think of it like ThreadPoolExecutor that can be extended and customized). To make this possible we extracted the whole IO handling / multiplexing to another class that is injected into the MultiThreadIoEventLoopGroup.

For example:

new EpollEventLoopGroup();

becomes

new MultiThreadIoEventLoopGroup(EpollIoHandler.newFactory();

Other transports follow the same pattern.

MultiThreadIoEventLoopGroup and SingleThreadIoEventLoop provide various methods that can be overridden by the user and so provide the ability to:

  • get a count of registered channels / handles
  • understand how long the io processing vs task processing took
  • how many channels / handles were processed per loop run
  • customize / decorate promises

Furthermore, it is now possible to register other things than Channels, which provides a lot of possibilites to re-use netty components and also add support for other IoHandle implementations which does not exists as of today. For example, this could be used to implement file IO with io_uring.

io_uring support

This release contains io_uring support for its transports based on our incubator version with changes related to the above mentioned EventLoopGroup changes.

Once 4.2.0 is considered stable we plan to stop mantaining the incubator version of io_uring and so only provide it for 4.2.x in the future.

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.