Netty System Properties: JDK 17 plus

[Nezisi]

The client side of Play framework uses Netty via async-http-client, which is integrated into Play-WS.

In Play-WS the Netty version is not upgradable without a full repackaging, as the Netty version is integrated into the shaded async-http-library.

Just a heads-up because the system properties affect to my understanding both server / client, and given the shading the system properties should be set for the shaded and non-shaded system property.

Netty uses for a better performance direct buffers, if the internal APIs required for it are not exposed / not accessible via reflection, netty should still work, but performance might suffer.

netty/netty#12265

System Property:
io.netty.tryReflectionSetAccessible=true (non-shaded -> Server)
play.shaded.ahc.io.netty.tryReflectionSetAccessible=true (shaded -> Play-WS / Client)

Java Flags:
--add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/jdk.internal.misc=ALL-UNNAMED

To allow reflection and expose the internal APIs, so Netty can use for example direct buffers.

Another system property that might be worth mentioning here and is set commonly:

io.netty.allocator.maxOrder=3 (non-shaded -> Server)
play.shaded.ahc.io.netty.allocator.maxOrder=3 (shaded -> Play-WS / Client)

The longer explanation is here:
https://programmer.group/pool-area-of-netty-memory-pool.html

The shorter explanation: It affects the depth of the binary tree Netty uses to allocate memory, according to
helidon-io/helidon#3801
it could be up to 16 MiB per thread.

Micronaut defaults to a max order of 3, too.

micronaut-projects/micronaut-core#9211

In our test runs with JDK 21 beta everything went smoothly and memory consumption went down, too.

EDIT: Play-WS needs to be repackaged to a current version of course, we chose the latest Netty version: 4.1.96 FINAL. These flags won't work in the current Play-WS version / without an up to date Netty.

@mkurz If you need help regarding Play-WS / removal of shading or other stuff, give a ping. :)