Netty On Open Liberty: Beta Preview & What You Need To Know

by SLV Team 60 views

Hey everyone! 👋 Today, we're diving into something pretty exciting: Open Liberty's new Netty-based HTTP transport, now available in beta! This is a big deal, so let's break down what it is, why it matters, and how you can get involved. Get ready to supercharge your applications with a modern, high-performance foundation! 🚀

What's the Buzz About Netty? 🐝

First things first: what is Netty? In a nutshell, Netty is a powerful, event-driven network application framework. Think of it as the engine that drives the underlying transport for HTTP/1.1, HTTP/2, WebSockets, JMS, and SIP communications within Open Liberty. The move to Netty means we're upgrading the internal plumbing, laying the groundwork for greater scalability, improved maintainability, and future performance enhancements. The beauty of this update? Zero migration is required! Your existing applications and server.xml configurations should work exactly as they always have. We're aiming for a seamless transition, so you can benefit from the improvements without rewriting your code.

This is a beta release, so your feedback is super important to us! We want to hear about your experiences, whether things are running smoothly or if you've hit any snags. Your input will help us fine-tune everything before the official launch, ensuring a rock-solid experience for everyone. So, let's get into the nitty-gritty and see how you can get involved.

The Benefits of Embracing Netty

Netty's event-driven I/O provides a modern foundation for long-term scalability, easier maintenance, and future performance enhancements. This means we can handle more traffic, make updates more easily, and continually optimize performance without requiring you to change any of your application's APIs or configuration. The key here is the modern foundation that allows us to be flexible and adapt to future performance improvements. This is a crucial step towards ensuring Open Liberty remains a top choice for developers looking for a robust and performant application server.

Who Should Care About This?

This beta release is particularly relevant for a few key players:

  • Application Developers: You'll want to validate that your applications continue to function as expected and that any performance metrics remain stable or improve.
  • Performance Engineers: This is your chance to put the new transport through its paces, measuring throughput, latency, and resource utilization under various loads.
  • Operations/Site Engineers: Ensure the new transport integrates smoothly with your existing infrastructure and that logging and monitoring systems are still working correctly.

How to Get Started with the Netty Beta 🕹️

Ready to jump in? The good news is, getting started is incredibly easy. Because it's designed for zero migration, you don't need to change anything in your application or server.xml to take advantage of the Netty-based HTTP transport. Simply use the current All Beta Features runtime for this release. That's it! Easy, right?

Step-by-Step Guide to Try the Netty Beta

  1. Ensure you're using the Open Liberty runtime that supports all Beta Features.
  2. Deploy your application: Deploy your existing applications to the runtime.
  3. Test your applications: Run performance tests and validate the applications. This includes testing HTTP/1.1, HTTP/2, WebSocket, JMS, and SIP functionality.
  4. Provide Feedback: Share your experience with the Open Liberty community.

What to Test: Put Netty Through Its Paces 🧪

To help us validate parity and performance, we're asking you to put the Netty-based transport through its paces with some real-world scenarios. Here are some key areas to focus on:

HTTP/1.1 and HTTP/2

  • Large Uploads/Downloads: Test the handling of substantial data transfers to ensure stability and performance.
  • Chunked Transfers: Verify that chunked encoding works as expected, particularly with streaming data.
  • Compression-Enabled Content: Confirm that content compression (e.g., gzip) is working correctly and that you observe the expected performance improvements.
  • Keep-Alive Behavior: Check that HTTP connections are reused efficiently, and that keep-alive timeouts are functioning properly.

WebSocket

  • Long-Lived Communications: Test your applications to ensure that WebSocket connections remain stable over extended periods.
  • Backpressure Scenarios: Simulate scenarios where the server might be overloaded, and verify that backpressure mechanisms are working to prevent resource exhaustion.

Timeouts

  • Read/Write/Keep-Alive Timeouts: Configure various timeouts and test to ensure that the server behaves as expected when connections are idle, slow to respond, or experience errors.

Access Logging

  • Formatting and Results: Ensure the access logs are correctly formatted and that the logged information is accurate.
  • Comparison: Compare the results from the new build with previous builds to ensure consistent logging behavior.

JMS Communications

  • Message Send/Receive Throughput: Measure the rate at which messages can be sent and received under various load conditions.
  • Durable Subscriptions: Verify that durable subscriptions are functioning correctly and that messages are delivered reliably.

Beta Release Limitations 🚧

While this is a significant step forward, it's a beta release, and there are some known limitations to be aware of. We're actively working on addressing these, and your feedback will help us prioritize our efforts. Here's a rundown:

HTTP

  • Large Content Length: HTTP requests with content lengths exceeding the maximum integer value may fail.
  • maxKeepAliveRequests: HTTP 1.1 has a maximum limit of 50 pipelined requests if no limits are set.
  • resetFramesWindow: Precision is reduced from milliseconds to seconds.
  • MessageSizeLimit: Capped at the maximum integer value for HTTP/2.0 connections.
  • ThrowIOEForInboundConnections: May behave differently from the Channel Framework implementation.
  • acceptThread and waitToAccept: These TCP options are ignored for now.
  • Clear Text Upgrade Requests: HTTP 2.0 with request data will be rejected. A fix is in progress.

WebSocket

  • FFDC RuntimeExceptions: May occur on connection cleanup.

SIP

  • SIP Resolver Transport: Does not currently use a Netty transport implementation.

ALPN

  • ALPN Implementation: Currently supports only the native JDK ALPN implementation. Additional implementations supported by the Channel Framework, but not yet in the Netty beta, are listed here. This might affect your applications. Make sure that you understand the limitations of the features that you are using.

Providing Feedback: Make Your Voice Heard 📣

Your feedback is crucial to the success of this beta. We want to know about your experiences, whether good, bad, or indifferent. Did your applications work flawlessly? Did you encounter any issues? Did you notice any performance improvements or regressions?

How to Give Feedback

  • Open Liberty Forums: The primary location for your comments and contributions.
  • GitHub Issues: Open an issue if you encounter bugs or have specific feature requests.
  • Direct Communication: Feel free to reach out to the Open Liberty team directly.

By providing feedback, you're not just helping us improve the Netty-based transport; you're also helping to shape the future of Open Liberty. Your insights will help us refine the implementation, address any issues, and ensure that the final release meets the needs of the community. Don't be shy – we appreciate every contribution.

Conclusion: Embrace the Future with Netty! 🎉

That's the scoop on the Netty-based HTTP transport beta in Open Liberty. We're excited about the potential of Netty to improve scalability, performance, and maintainability. Remember, this is a beta, so your feedback is critical. Please take some time to test it out, explore the new features, and share your experiences with the community. Together, we can make Open Liberty even better! Thanks for being a part of this journey! 🙌