Skip navigation

Netty 4.1.65.Final released

by normanmaurer
on

We are happy to announce the release of netty 4.1.65.Final, which beside fixes multiple bugs and includes some performance improvements as well. As netty 4.1.64.Final did include two regressions which were found quickly after the release we decided to not announce it all and just roll a 4.1.65.Final which includes everything.

The most important changes are:

  • Fire SslHandshakeCompletionEvent after the last decoded data chunk (#11148)
  • Log fewer stack traces from initialisation code (#11164)
  • Fix StreamBufferingEncoder GOAWAY bug (#11144)
  • Ensure DnsNameResolver resolves the host(computer) name on Windows (#11167)
  • Fix support for IP_RECVORIGDSTADDR when using native epoll transport (#11173)
  • BouncyCastle support (#11157)
  • SimpleChannelPromiseAggregator use first exception instead of last (#11168)
  • Add a new HTTP/2 pseudo header :protocol (#11192)
  • Enable TLSv1.3 when using BouncyCastle ALPN support (#11193)
  • Correctly throw ErrorDataDecoderException for errors while decoding (#11198)
  • Destroy HttpPostMultipartRequestDecoder if contructor throws (#11207)
  • ReferenceCountedOpenSslEngine unwrap handshake complete status fix (#11210)
  • Fix Memory release not correctly in Multipart Decoder (#11188)
  • Preload classes before calling native OnLoad function to prevent classloader deadlock (#11215)
  • Only fall back to CNAME on A/AAAA queries (#11216)
  • Re-order list of resolvers according to their searchOrder (#11236)
  • Disable TLSv1 and TLSv1.1 by default (#11237)
  • Use tasks by default when using openssl based SSL provider (#11242)
  • Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file's entries for a hostname (#11246)
  • Introduce BrotliDecoder (#10960)
  • Fix loading of the native library for DNS resolution on MacOS (#11260)

For the details and all changes, please browse our issue tracker for 4.1.65.Final and 4.1.6.4.Final

Important notes

Classloader deadlock workaround

It seems like more recent version of the JDK can trigger a classloader deadlock easily when trying to load our JNI based code. This release includes a work-around for this while the OpenJDK developers are investigating on how this can be fixed in the OpenJDK itself. For more details please check (#11215), which contains all the related links.

Disable TLSv1 and TLSv1.1 by default

As TLSv1 and TLSv1.1 are considered insecure and are also disabled by default now in the OpenJDK we did follow the same path here. That said if you still need to supported these you can explicit enable them when using the SslContextBuilder to build the SslContext.

HTTP Brotli support

To be able to make use of the new BrotliDecoder you need to ensure the Brotli4J jars are on your class-path.

For example if you use maven this would be done by specify the following dependencies:

<dependency>
    <groupId>com.aayushatharva.brotli4j</groupId>
    <artifactId>brotli4j</artifactId>
    <scope>runtime</scope>
    <version>1.4.2</version>
</dependency>
<dependency>
    <groupId>com.aayushatharva.brotli4j</groupId>
    <artifactId>native-linux-x86_64</artifactId>
    <scope>runtime</scope>
    <version>1.4.2</version>
</dependency>
<dependency>
    <groupId>com.aayushatharva.brotli4j</groupId>
    <artifactId>native-osx-x86_64</artifactId>
    <scope>runtime</scope>
    <version>1.4.2</version>
</dependency>
<dependency>
    <groupId>com.aayushatharva.brotli4j</groupId>
    <artifactId>native-windows-x86_64</artifactId>
    <scope>runtime</scope>
    <version>1.4.2</version>
</dependency>

Once the dependencies are added HTTP decompression for brotli will be supported out of the box.

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.