Oh man, this hint was *extremely* useful because it fully explains why we are seeing the behaviour only in some cases and not in others. In one case the container only sees one CPU (=> 3 threads, no problem) in another case it sees 16 (=> 48 threads, causes a problem).
Thanks! Thorsten Am Dienstag, dem 14.10.2025 um 12:43 +0100 schrieb Robbie Gemmell: > I believe those threads are tied to an event group loop, essentially > acting as a thread pool over time. Perhaps follow to/from > https://github.com/apache/activemq-artemis/blob/2.42.0/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyConnector.java#L531-L534 > > (note: if looking on main, or the 2.43.0 candidate under vote, the > name of the threads changed since 2.42.0) > > On Tue, 14 Oct 2025 at 10:13, Thorsten Meinl > <[email protected]> wrote: > > > > Attached is a reproducer for the behaviour. Run with > > > > mvn compile exec:java > > > > and monitor the output with the active threads. It's constantly > > increasing to 56 (in my case) and then stays constant. Therefore I > > don't think it's an actual issue since the number of threads seems > > to > > be bounded after all but I find the behaviour strange nevertheless. > > > > After some debugging I also believe that these threads ("ActiveMQ- > > client-netty-threads") are _not_ part of a thread pool but somehow > > tied > > to the JMS context and not cleaned up right after the context is > > closed. > > > > For us this means we just need to provide a bit more of direct > > memory, > > 20MB seems to be sufficient. > > > > Cheers, > > > > Thorsten > > > > > > Am Montag, dem 13.10.2025 um 12:04 -0500 schrieb Justin Bertram: > > > It's hard to comment without more details. Is this the same > > > client as > > > before that's using 2.42.0? What connection URL are you using? Do > > > you > > > have > > > a reproducer you could share? Is this a regression or a new > > > issue? > > > > > > This documentation [1] might be of some help. > > > > > > Out of curiosity, what is the purpose of the management message? > > > I'm > > > always > > > trying to understand better how folks use our software, > > > especially > > > the > > > management API, so we can add new features or improve existing > > > ones. > > > > > > > > > Justin > > > > > > [1] > > > https://activemq.apache.org/components/artemis/documentation/latest/thread-pooling.html#client-side-thread-management > > > > > > On Mon, Oct 13, 2025 at 11:15 AM Thorsten Meinl > > > <[email protected]> > > > wrote: > > > > > > > Good evening, > > > > > > > > I am tracking down (yet another) memory issue on one of our > > > > Artemis > > > > client applications. We set very low limits for direct memory > > > > that > > > > Java > > > > is allowed to use, 13MB in this particular case. After starting > > > > the > > > > application, the "direct buffers" in use increase up to when no > > > > more > > > > direct memory can be allocated. The application does not do > > > > anything > > > > than listen on a topic and send and consume a management > > > > message > > > > every > > > > 30 seconds. It does _not_ consume or send any other messages. > > > > Yet, > > > > I > > > > see 47 "ActiveMQ-client-netty-threads" threads existing. All of > > > > them > > > > are idle in "io.netty.channel.epoll.Native.epollWait". If all > > > > of > > > > these > > > > threads use some thread-local netty buffer it would explain the > > > > constant growth. Which brings me to the main question: why > > > > would > > > > one > > > > see 47 such threads if there is almost nothing going on in the > > > > application? I would assume that a handful of threads should be > > > > sufficient since they can easily get re-used. > > > > > > > > Cheers, > > > > > > > > Thorsten > > > > > > > > -- > > > > Dr.-Ing. Thorsten Meinl > > > > KNIME AG > > > > Talacker 50 > > > > 8001 Zurich, Switzerland > > > > > > > > > > > > --------------------------------------------------------------- > > > > ---- > > > > -- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > For further information, visit: > > > > https://activemq.apache.org/contact > > > > > > > > > > > > > > > > -- > > Dr.-Ing. Thorsten Meinl > > KNIME AG > > Talacker 50 > > 8001 Zurich, Switzerland > > > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > For further information, visit: https://activemq.apache.org/contact > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > For further information, visit: https://activemq.apache.org/contact > -- Dr.-Ing. Thorsten Meinl KNIME AG Talacker 50 8001 Zurich, Switzerland --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
