You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The blocking thread pool of Quarkus is extending Netty's FastThreadLocalThread for several reasons (@cescoffier knows more on this), but it leads to 2 problems:
In case idle (non-core) threads get killed and recreated, new PoolThreadCaches allocations can still cause extending existing allocation(s) off-heap arena, which with glibc, can cause a spike in memory usage (more info at https://sourceware.org/bugzilla/show_bug.cgi?id=11261)
Ideally if jboss-thread(s) Threads won't be FastThreadLocalThreads it will just work fine, because useCacheForAllThreads is false by default. Another option, instead, similar to #39061, is to use heap-based unpooled buffers, but given that core jboss-thread(s) are long living, will likely impact performance.
franz1981
changed the title
JBossThread memory footprint and risk of CVE/OOM due to FastThreadLocal usage
JBossThread memory footprint and risk of OOM due to FastThreadLocal usage
Feb 28, 2024
franz1981
changed the title
JBossThread memory footprint and risk of OOM due to FastThreadLocal usage
JBossThread (off-heap) memory footprint due to FastThreadLocal usage
Feb 28, 2024
The blocking thread pool of Quarkus is extending Netty's
FastThreadLocalThread
for several reasons (@cescoffier knows more on this), but it leads to 2 problems:Recycler
s and, even worse,PoolThreadCache
(at https://github.com/netty/netty/blob/4ba1c3e7e190bdc9bdd0ece237042f16e843c797/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java#L525) which can become pretty big and stay still on idle threads too, without being available to othersPoolThreadCache
s allocations can still cause extending existing allocation(s) off-heap arena, which with glibc, can cause a spike in memory usage (more info at https://sourceware.org/bugzilla/show_bug.cgi?id=11261)Ideally if jboss-thread(s)
Thread
s won't beFastThreadLocalThread
s it will just work fine, becauseuseCacheForAllThreads
is false by default. Another option, instead, similar to #39061, is to use heap-based unpooled buffers, but given that core jboss-thread(s) are long living, will likely impact performance.There's another option to investigate which periodically schedule trimming of thread local caches (see https://github.com/netty/netty/blob/4ba1c3e7e190bdc9bdd0ece237042f16e843c797/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java#L127-L145), but sadly it will be applied to event loops/I/O threads too, which is not something we want (I believe).
The text was updated successfully, but these errors were encountered: