Enabling SSL can double RSS due to Netty off-heap arenas

[franz1981]

This is due to eclipse-vertx/vert.x#5168 (comment)
and will be "fixed" via eclipse-vertx/vert.x#5262

TLDR: enabling SSL make Vertx to use a custom off-heap pooled allocator for I/O (e.g. while reading or copying heap to off-heap to send data on the wire), but Jackson (and other quarkus parts) uses the Netty default one, making both to be resident in memory and doubling the required capacity.

This is the Jackson one:

quarkus/independent-projects/vertx-utils/src/main/java/io/quarkus/vertx/utils/AppendBuffer.java

Line 136 in 261cc87

tmpBuf = PooledByteBufAllocator.DEFAULT.directBuffer(chunkCapacity);

A complete fix should be able to correctly pass the allocator associated to the vertx connection to the above append buffer, saving to directly reference it.

A simple(r) and less invasive fix, instead, should change the above code to use the vertx pooled allocator, instead, given that via eclipse-vertx/vert.x#5262 it should be the default used.

[quarkus-bot]

/cc @cescoffier (netty), @jponge (netty)

[franz1981]

This issue wasn't accurate enough: eclipse-vertx/vert.x#5292 (comment) describe a non-SSL case where the pooled allocators can still be duplicated - although it shouldn't be used, making the cost to just be in the empty arenas/data structures of the allocator.

[franz1981]

Ping for @mabartos : keycloak uses the JDK SSL engine by default? Is it a common use for users?

[mabartos]

@franz1981 For the server, we just rely on Quarkus internals with regards to TLS. For other stuff (HTTP client, remote Infinispan,...) we use SSL context obtained from JDK. AFAIK there is no explicit usage of SSLEngine in Keycloak, as mentioned here, and no other impls used as OpenSSL.

Perhaps @pedroigor or @vmuzikar might have more information if necessary.

[franz1981]

For the server, we just rely on Quarkus internals with regards to TLS

which means the JDK SSL engine sadly .-.
see #41880
we don't yet support exposing any other ATM