back to all blogsSee all blog posts

Netty‑based HTTP transport in 26.0.0.6-beta

image of author
Navaneeth S Nair on Jun 2, 2026
Post available in languages:

This beta release introduces a preview of a Netty-based HTTP transport in Open Liberty, providing a modern, scalable foundation for HTTP and related communication protocols.

The Open Liberty 26.0.0.6-beta includes the following beta features (along with all GA features):

Netty‑based HTTP transport

Open Liberty now provides a Netty‑based HTTP transport as a beta preview. This is an internal implementation swap for the underlying transport used for HTTP/1.1, HTTP/2, WebSocket, JMS, and SIP communications. Compared to previous releases, the key update in this release is the fix for the user-reported 100-continue issue. It is designed for zero migration: your applications and server.xml file should continue to behave the same. We are looking forward and counting on your feedback before GA!

  • Target persona: Application developers, performance engineers, and operations/site engineers who need to validate application behavior, measure throughput, and monitor observability.

  • Why it matters: Netty’s event-driven I/O model provides a modern foundation for long-term scalability, easier maintenance, and future performance enhancements— all without requiring changes to your APIs or configuration!

How to use it:

No changes are required to benefit from the current All Beta Features runtime for this release.

To help validate parity and performance for your real-world scenarios, try testing these areas:

  • HTTP/1.1 and HTTP/2: Large uploads or downloads, chunked transfers, compression-enabled content, keep-alive behavior.

  • WebSocket: Long-lived communications, backpressure scenarios

  • Timeouts: Read/write/keep-alive timeouts under load

  • Access logging: Verify formatting and log results compared to previous builds

  • JMS communications: Messages send/receive throughput, durable subscriptions

Limitations of the Beta release:

  • HTTP

    • HTTP requests with content length greater than the maximum integer value fail due to internal limitations on request size with Netty.

    • When the HTTP option maxKeepAliveRequests is unlimited, HTTP 1.1 supports a maximum of 50 pipelined requests.

    • The HTTP option resetFramesWindow is reduced from millisecond to second precision due to limitations in the Netty library.

    • Due to internal limitations of the Netty library, the HTTP option MessageSizeLimit is now adjusted to be capped at the maximum integer value for HTTP/2.0 connections.

    • Due to internal differences with Netty, the HTTP option ThrowIOEForInboundConnections can behave differently from the Channel Framework implementation.

    • Due to internal limitations of Netty, the TCP options acceptThread and waitToAccept are not implemented in this Beta and are ignored if set.

  • WebSocket

    • WebSocket inbound requests can generate First Failure Data Capture RuntimeExceptions on connection cleanup when a connection is closed from the client side.

  • Application-Layer Protocol Negotiation (ALPN)

    • Currently, our Netty implementation supports only the native JDK ALPN implementation. Additional information for the ALPN implementations that are currently supported by the Channel Framework but not our Netty beta can be found in the ALPN documentation.

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 21, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.12.0</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>26.0.0.6-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, the following block adds dependencies for two example beta APIs:

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:4.0.0'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[26.0.0.6-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging and application management all from within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.