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
<<attachment: artemis-test.zip>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
