You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Thorsten Meinl <th...@knime.com> on 2025/10/07 15:37:31 UTC

Potential memory leak in Artemis JMS client

Hi,

We are using the Artemis JMS client 2.42.0 in an application with the
following pattern:

try (var context =
connectionFactory.createContext(Session.SESSION_TRANSACTED);
    var consumer = context.createSharedDurableConsumer(topic,
queueName, QUEUE_FILTER)) {
     while (!Thread.currentThread().isInterrupted()) {
        var message = consumer.receive();
        if (message == null) {
             break;
        }
	// do some stuff
	context.commit();
    }
}

The service regularly runs out of memory after some time. We created a
heap dump and found some data structures deep in the Artemis client of
more than 500MB while our messages are are in almost all cases below
1MB in some exceptional cases up to 20MB. I have attached a snippet of
the heap dump.
Is this an issue in the client code or are we doing something wrong in
our application code?

Thanks,

Thorsten


-- 
Dr.-Ing. Thorsten Meinl
KNIME AG
Talacker 50
8001 Zurich, Switzerland

Re: Potential memory leak in Artemis JMS client

Posted by Justin Bertram <jb...@apache.org>.
FYI - the new version of Johnzon has finally been released, and I've sent a
PR to get it into Artemis. There is currently an Artemis release in
progress so this fix will be available in the next release (i.e. 2.45.0).


Justin

On Mon, Oct 13, 2025 at 11:23 AM Justin Bertram <jb...@apache.org> wrote:

> FYI - A new 1.2.x version of Johnzon is proceeding through the release
> process. It should be available soon.
>
>
> Justin
>
> On Thu, Oct 9, 2025 at 1:37 PM Thorsten Meinl <th...@knime.com>
> wrote:
>
>> Am Donnerstag, dem 09.10.2025 um 12:08 -0500 schrieb Justin Bertram:
>> > > Shall I open a Jira issue for the issue?
>> > Yes.
>> Here it is: https://issues.apache.org/jira/browse/ARTEMIS-5699
>>
>> > FYI - I sent an email to the Johnzon dev list [1] to inquire about
>> > getting
>> > a 1.2.x release with this fix.
>> Thanks for following up!
>>
>> Cheers,
>>
>> Thorsten
>>
>> > On Thu, Oct 9, 2025 at 6:18 AM Thorsten Meinl
>> > <th...@knime.com>
>> > wrote:
>> >
>> > > I have re-implemented the three methods that extract the response
>> > > data
>> > > from from management messages using a different Json parser. The
>> > > memory
>> > > leak is gone now.
>> > >
>> > > Shall I open a Jira issue for the issue?
>> > >
>> > > Thorsten
>> > >
>> > > Am Mittwoch, dem 08.10.2025 um 11:30 -0500 schrieb Justin Bertram:
>> > > > The fix for this issue is actually on the branch for 1.2.x [1],
>> > > > but
>> > > > there
>> > > > hasn't been a 1.2 release to include it.
>> > > >
>> > > > I was under the impression that the current javax branch (i.e.
>> > > > for
>> > > > 1.2.x)
>> > > > and the jakarta branch (i.e. for 2.x) would be maintained in
>> > > > parallel. I'll
>> > > > have to dig around and probably get in touch with the Johnzon
>> > > > developers to
>> > > > get to the bottom of this.
>> > > >
>> > > >
>> > > > Justin
>> > > >
>> > > > [1]
>> > > >
>> > >
>> https://github.com/apache/johnzon/commit/664cb73f629fd0190902a0f1080c420a509e66b0
>> > > >
>> > > > On Wed, Oct 8, 2025 at 9:59 AM Thorsten Meinl
>> > > > <th...@knime.com>
>> > > > wrote:
>> > > >
>> > > > > I found it: it's
>> > > > > https://issues.apache.org/jira/browse/JOHNZON-396
>> > > > > It's fixed in version 2.0.1 but since Artemis is shading the
>> > > > > old
>> > > > > version 1.21 the bug is still present. It affects all responses
>> > > > > from
>> > > > > the broker that contain a string larger than ~200kB. In our
>> > > > > case a
>> > > > > list
>> > > > > of around 4,400 addresses.
>> > > > >
>> > > > > Is there a way to access the value in the response without
>> > > > > using
>> > > > > the
>> > > > > buggy JSON parser?
>> > > > >
>> > > > > Thorsten
>> > > > >
>> > > > > Am Dienstag, dem 07.10.2025 um 15:17 -0500 schrieb Justin
>> > > > > Bertram:
>> > > > > > Are you doing anything else with JMS and/or Artemis-specific
>> > > > > > code
>> > > > > > in
>> > > > > > your
>> > > > > > application other than this snippet you pasted?
>> > > > > >
>> > > > > > Unfortunately I don't have any hunches about what the problem
>> > > > > > might
>> > > > > > be.
>> > > > > > This code has been in place for years and this is the first
>> > > > > > time
>> > > > > > I
>> > > > > > can
>> > > > > > recall ever seeing any kind of issue with it - memory or
>> > > > > > otherwise. I
>> > > > > > was
>> > > > > > hoping to get some clues about the problem based on a more
>> > > > > > detailed
>> > > > > > description of your use-case. It would be helpful to
>> > > > > > understand
>> > > > > > everything
>> > > > > > your application is doing with JMS and any Artemis-specific
>> > > > > > implementation
>> > > > > > classes.
>> > > > > >
>> > > > > >
>> > > > > > Justin
>> > > > > >
>> > > > > > On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl
>> > > > > > <th...@knime.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin
>> > > > > > > Bertram:
>> > > > > > > > The image indicates there's accumulation related to JSON
>> > > > > > > > parsing
>> > > > > > > > which I
>> > > > > > > > wouldn't expect during the normal process of consuming a
>> > > > > > > > message.
>> > > > > > > >
>> > > > > > > > Can you share any more details about your use-case?
>> > > > > > > Not sure what details you need, but we access the message
>> > > > > > > body
>> > > > > > > with
>> > > > > > > getBody(byte[].class) as well as some string properties. We
>> > > > > > > also
>> > > > > > > send
>> > > > > > > very similar messages from the same application (also with
>> > > > > > > a
>> > > > > > > byte[]
>> > > > > > > body) inside the same transaction. Afterwards the JMS
>> > > > > > > context
>> > > > > > > is
>> > > > > > > committed. And then it repeats.
>> > > > > > >
>> > > > > > > > Do you have a reproducer?
>> > > > > > > Not yet, I can work on one.
>> > > > > > >
>> > > > > > > >  Are the client and the broker in the same JVM?
>> > > > > > > No.
>> > > > > > >
>> > > > > > > Do you have any suspicion where to look closer? I am happy
>> > > > > > > to
>> > > > > > > debug
>> > > > > > > myself if I get some pointers. This might be easier than
>> > > > > > > stripping
>> > > > > > > everything down to a minimal reproducer.
>> > > > > > >
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > >
>> > > > > > > Thorsten
>> > > > > > >
>> > > > > > >
>> > > > > > > > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
>> > > > > > > > <th...@knime.com>
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Bummer. I hope this works:
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > >
>> > > > >
>> > >
>> https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
>> > > > > > > > >
>> > > > > > > > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb
>> > > > > > > > > Justin
>> > > > > > > > > Bertram:
>> > > > > > > > > > I believe your attachment was stripped by the mailing
>> > > > > > > > > > list.
>> > > > > > > > > > Could
>> > > > > > > > > > you
>> > > > > > > > > > provide a link to it?
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Justin
>> > > > > > > > > >
>> > > > > > > > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
>> > > > > > > > > > <th...@knime.com>
>> > > > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Hi,
>> > > > > > > > > > >
>> > > > > > > > > > > We are using the Artemis JMS client 2.42.0 in an
>> > > > > > > > > > > application
>> > > > > > > > > > > with
>> > > > > > > > > > > the
>> > > > > > > > > > > following pattern:
>> > > > > > > > > > >
>> > > > > > > > > > > try (var context =
>> > > > > > > > > > > connectionFactory.createContext(Session.SESSION_TRA
>> > > > > > > > > > > NSAC
>> > > > > > > > > > > TED)
>> > > > > > > > > > > ;
>> > > > > > > > > > >     var consumer =
>> > > > > > > > > > > context.createSharedDurableConsumer(topic,
>> > > > > > > > > > > queueName, QUEUE_FILTER)) {
>> > > > > > > > > > >      while
>> > > > > > > > > > > (!Thread.currentThread().isInterrupted()) {
>> > > > > > > > > > >         var message = consumer.receive();
>> > > > > > > > > > >         if (message == null) {
>> > > > > > > > > > >              break;
>> > > > > > > > > > >         }
>> > > > > > > > > > >         // do some stuff
>> > > > > > > > > > >         context.commit();
>> > > > > > > > > > >     }
>> > > > > > > > > > > }
>> > > > > > > > > > >
>> > > > > > > > > > > The service regularly runs out of memory after some
>> > > > > > > > > > > time.
>> > > > > > > > > > > We
>> > > > > > > > > > > created a
>> > > > > > > > > > > heap dump and found some data structures deep in
>> > > > > > > > > > > the
>> > > > > > > > > > > Artemis
>> > > > > > > > > > > client
>> > > > > > > > > > > of
>> > > > > > > > > > > more than 500MB while our messages are are in
>> > > > > > > > > > > almost
>> > > > > > > > > > > all
>> > > > > > > > > > > cases
>> > > > > > > > > > > below
>> > > > > > > > > > > 1MB in some exceptional cases up to 20MB. I have
>> > > > > > > > > > > attached a
>> > > > > > > > > > > snippet
>> > > > > > > > > > > of
>> > > > > > > > > > > the heap dump.
>> > > > > > > > > > > Is this an issue in the client code or are we doing
>> > > > > > > > > > > something
>> > > > > > > > > > > wrong
>> > > > > > > > > > > in
>> > > > > > > > > > > our application code?
>> > > > > > > > > > >
>> > > > > > > > > > > Thanks,
>> > > > > > > > > > >
>> > > > > > > > > > > Thorsten
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > --
>> > > > > > > > > > > Dr.-Ing. Thorsten Meinl
>> > > > > > > > > > > KNIME AG
>> > > > > > > > > > > Talacker 50
>> > > > > > > > > > > 8001 Zurich, Switzerland
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > ---------------------------------------------------
>> > > > > > > > > > > ----
>> > > > > > > > > > > ----
>> > > > > > > > > > > ----
>> > > > > > > > > > > ----
>> > > > > > > > > > > --
>> > > > > > > > > > > To unsubscribe, e-mail:
>> > > > > > > > > > > users-unsubscribe@activemq.apache.org
>> > > > > > > > > > > For additional commands, e-mail:
>> > > > > > > > > > > users-help@activemq.apache.org
>> > > > > > > > > > > For further information, visit:
>> > > > > > > > > > > https://activemq.apache.org/contact
>> > > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > > Dr.-Ing. Thorsten Meinl
>> > > > > > > > > KNIME AG
>> > > > > > > > > Talacker 50
>> > > > > > > > > 8001 Zurich, Switzerland
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > -------------------------------------------------------
>> > > > > > > > > ----
>> > > > > > > > > ----
>> > > > > > > > > ----
>> > > > > > > > > --
>> > > > > > > > > To unsubscribe, e-mail:
>> > > > > > > > > users-unsubscribe@activemq.apache.org
>> > > > > > > > > For additional commands, e-mail:
>> > > > > > > > > users-help@activemq.apache.org
>> > > > > > > > > For further information, visit:
>> > > > > > > > > https://activemq.apache.org/contact
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Dr.-Ing. Thorsten Meinl
>> > > > > > > KNIME AG
>> > > > > > > Talacker 50
>> > > > > > > 8001 Zurich, Switzerland
>> > > > > > >
>> > > > > > >
>> > > > > > > -----------------------------------------------------------
>> > > > > > > ----
>> > > > > > > ----
>> > > > > > > --
>> > > > > > > To unsubscribe, e-mail:
>> > > > > > > users-unsubscribe@activemq.apache.org
>> > > > > > > For additional commands, e-mail:
>> > > > > > > users-help@activemq.apache.org
>> > > > > > > For further information, visit:
>> > > > > > > https://activemq.apache.org/contact
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > >
>> > > > > --
>> > > > > Dr.-Ing. Thorsten Meinl
>> > > > > KNIME AG
>> > > > > Talacker 50
>> > > > > 8001 Zurich, Switzerland
>> > > > >
>> > > > >
>> > > > > ---------------------------------------------------------------
>> > > > > ----
>> > > > > --
>> > > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
>> > > > > For additional commands, e-mail: users-help@activemq.apache.org
>> > > > > For further information, visit:
>> > > > > https://activemq.apache.org/contact
>> > > > >
>> > > > >
>> > > > >
>> > >
>> > > --
>> > > Dr.-Ing. Thorsten Meinl
>> > > KNIME AG
>> > > Talacker 50
>> > > 8001 Zurich, Switzerland
>> > >
>> > >
>> > > -------------------------------------------------------------------
>> > > --
>> > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
>> > > For additional commands, e-mail: users-help@activemq.apache.org
>> > > For further information, visit: https://activemq.apache.org/contact
>> > >
>> > >
>> > >
>>
>> --
>> Dr.-Ing. Thorsten Meinl
>> KNIME AG
>> Talacker 50
>> 8001 Zurich, Switzerland
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
>> For additional commands, e-mail: users-help@activemq.apache.org
>> For further information, visit: https://activemq.apache.org/contact
>>
>>
>>

Re: Potential memory leak in Artemis JMS client

Posted by Justin Bertram <jb...@apache.org>.
FYI - A new 1.2.x version of Johnzon is proceeding through the release
process. It should be available soon.


Justin

On Thu, Oct 9, 2025 at 1:37 PM Thorsten Meinl <th...@knime.com>
wrote:

> Am Donnerstag, dem 09.10.2025 um 12:08 -0500 schrieb Justin Bertram:
> > > Shall I open a Jira issue for the issue?
> > Yes.
> Here it is: https://issues.apache.org/jira/browse/ARTEMIS-5699
>
> > FYI - I sent an email to the Johnzon dev list [1] to inquire about
> > getting
> > a 1.2.x release with this fix.
> Thanks for following up!
>
> Cheers,
>
> Thorsten
>
> > On Thu, Oct 9, 2025 at 6:18 AM Thorsten Meinl
> > <th...@knime.com>
> > wrote:
> >
> > > I have re-implemented the three methods that extract the response
> > > data
> > > from from management messages using a different Json parser. The
> > > memory
> > > leak is gone now.
> > >
> > > Shall I open a Jira issue for the issue?
> > >
> > > Thorsten
> > >
> > > Am Mittwoch, dem 08.10.2025 um 11:30 -0500 schrieb Justin Bertram:
> > > > The fix for this issue is actually on the branch for 1.2.x [1],
> > > > but
> > > > there
> > > > hasn't been a 1.2 release to include it.
> > > >
> > > > I was under the impression that the current javax branch (i.e.
> > > > for
> > > > 1.2.x)
> > > > and the jakarta branch (i.e. for 2.x) would be maintained in
> > > > parallel. I'll
> > > > have to dig around and probably get in touch with the Johnzon
> > > > developers to
> > > > get to the bottom of this.
> > > >
> > > >
> > > > Justin
> > > >
> > > > [1]
> > > >
> > >
> https://github.com/apache/johnzon/commit/664cb73f629fd0190902a0f1080c420a509e66b0
> > > >
> > > > On Wed, Oct 8, 2025 at 9:59 AM Thorsten Meinl
> > > > <th...@knime.com>
> > > > wrote:
> > > >
> > > > > I found it: it's
> > > > > https://issues.apache.org/jira/browse/JOHNZON-396
> > > > > It's fixed in version 2.0.1 but since Artemis is shading the
> > > > > old
> > > > > version 1.21 the bug is still present. It affects all responses
> > > > > from
> > > > > the broker that contain a string larger than ~200kB. In our
> > > > > case a
> > > > > list
> > > > > of around 4,400 addresses.
> > > > >
> > > > > Is there a way to access the value in the response without
> > > > > using
> > > > > the
> > > > > buggy JSON parser?
> > > > >
> > > > > Thorsten
> > > > >
> > > > > Am Dienstag, dem 07.10.2025 um 15:17 -0500 schrieb Justin
> > > > > Bertram:
> > > > > > Are you doing anything else with JMS and/or Artemis-specific
> > > > > > code
> > > > > > in
> > > > > > your
> > > > > > application other than this snippet you pasted?
> > > > > >
> > > > > > Unfortunately I don't have any hunches about what the problem
> > > > > > might
> > > > > > be.
> > > > > > This code has been in place for years and this is the first
> > > > > > time
> > > > > > I
> > > > > > can
> > > > > > recall ever seeing any kind of issue with it - memory or
> > > > > > otherwise. I
> > > > > > was
> > > > > > hoping to get some clues about the problem based on a more
> > > > > > detailed
> > > > > > description of your use-case. It would be helpful to
> > > > > > understand
> > > > > > everything
> > > > > > your application is doing with JMS and any Artemis-specific
> > > > > > implementation
> > > > > > classes.
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl
> > > > > > <th...@knime.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin
> > > > > > > Bertram:
> > > > > > > > The image indicates there's accumulation related to JSON
> > > > > > > > parsing
> > > > > > > > which I
> > > > > > > > wouldn't expect during the normal process of consuming a
> > > > > > > > message.
> > > > > > > >
> > > > > > > > Can you share any more details about your use-case?
> > > > > > > Not sure what details you need, but we access the message
> > > > > > > body
> > > > > > > with
> > > > > > > getBody(byte[].class) as well as some string properties. We
> > > > > > > also
> > > > > > > send
> > > > > > > very similar messages from the same application (also with
> > > > > > > a
> > > > > > > byte[]
> > > > > > > body) inside the same transaction. Afterwards the JMS
> > > > > > > context
> > > > > > > is
> > > > > > > committed. And then it repeats.
> > > > > > >
> > > > > > > > Do you have a reproducer?
> > > > > > > Not yet, I can work on one.
> > > > > > >
> > > > > > > >  Are the client and the broker in the same JVM?
> > > > > > > No.
> > > > > > >
> > > > > > > Do you have any suspicion where to look closer? I am happy
> > > > > > > to
> > > > > > > debug
> > > > > > > myself if I get some pointers. This might be easier than
> > > > > > > stripping
> > > > > > > everything down to a minimal reproducer.
> > > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Thorsten
> > > > > > >
> > > > > > >
> > > > > > > > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> > > > > > > > <th...@knime.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Bummer. I hope this works:
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > > > > > > > >
> > > > > > > > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb
> > > > > > > > > Justin
> > > > > > > > > Bertram:
> > > > > > > > > > I believe your attachment was stripped by the mailing
> > > > > > > > > > list.
> > > > > > > > > > Could
> > > > > > > > > > you
> > > > > > > > > > provide a link to it?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Justin
> > > > > > > > > >
> > > > > > > > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > > > > > > > > <th...@knime.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > We are using the Artemis JMS client 2.42.0 in an
> > > > > > > > > > > application
> > > > > > > > > > > with
> > > > > > > > > > > the
> > > > > > > > > > > following pattern:
> > > > > > > > > > >
> > > > > > > > > > > try (var context =
> > > > > > > > > > > connectionFactory.createContext(Session.SESSION_TRA
> > > > > > > > > > > NSAC
> > > > > > > > > > > TED)
> > > > > > > > > > > ;
> > > > > > > > > > >     var consumer =
> > > > > > > > > > > context.createSharedDurableConsumer(topic,
> > > > > > > > > > > queueName, QUEUE_FILTER)) {
> > > > > > > > > > >      while
> > > > > > > > > > > (!Thread.currentThread().isInterrupted()) {
> > > > > > > > > > >         var message = consumer.receive();
> > > > > > > > > > >         if (message == null) {
> > > > > > > > > > >              break;
> > > > > > > > > > >         }
> > > > > > > > > > >         // do some stuff
> > > > > > > > > > >         context.commit();
> > > > > > > > > > >     }
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > The service regularly runs out of memory after some
> > > > > > > > > > > time.
> > > > > > > > > > > We
> > > > > > > > > > > created a
> > > > > > > > > > > heap dump and found some data structures deep in
> > > > > > > > > > > the
> > > > > > > > > > > Artemis
> > > > > > > > > > > client
> > > > > > > > > > > of
> > > > > > > > > > > more than 500MB while our messages are are in
> > > > > > > > > > > almost
> > > > > > > > > > > all
> > > > > > > > > > > cases
> > > > > > > > > > > below
> > > > > > > > > > > 1MB in some exceptional cases up to 20MB. I have
> > > > > > > > > > > attached a
> > > > > > > > > > > snippet
> > > > > > > > > > > of
> > > > > > > > > > > the heap dump.
> > > > > > > > > > > Is this an issue in the client code or are we doing
> > > > > > > > > > > something
> > > > > > > > > > > wrong
> > > > > > > > > > > in
> > > > > > > > > > > our application code?
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > >
> > > > > > > > > > > Thorsten
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > > > > > KNIME AG
> > > > > > > > > > > Talacker 50
> > > > > > > > > > > 8001 Zurich, Switzerland
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ---------------------------------------------------
> > > > > > > > > > > ----
> > > > > > > > > > > ----
> > > > > > > > > > > ----
> > > > > > > > > > > ----
> > > > > > > > > > > --
> > > > > > > > > > > To unsubscribe, e-mail:
> > > > > > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > > > > > For additional commands, e-mail:
> > > > > > > > > > > users-help@activemq.apache.org
> > > > > > > > > > > For further information, visit:
> > > > > > > > > > > https://activemq.apache.org/contact
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > > > KNIME AG
> > > > > > > > > Talacker 50
> > > > > > > > > 8001 Zurich, Switzerland
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > -------------------------------------------------------
> > > > > > > > > ----
> > > > > > > > > ----
> > > > > > > > > ----
> > > > > > > > > --
> > > > > > > > > To unsubscribe, e-mail:
> > > > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > > > > > > > users-help@activemq.apache.org
> > > > > > > > > For further information, visit:
> > > > > > > > > https://activemq.apache.org/contact
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > KNIME AG
> > > > > > > Talacker 50
> > > > > > > 8001 Zurich, Switzerland
> > > > > > >
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > For additional commands, e-mail:
> > > > > > > users-help@activemq.apache.org
> > > > > > > For further information, visit:
> > > > > > > https://activemq.apache.org/contact
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Dr.-Ing. Thorsten Meinl
> > > > > KNIME AG
> > > > > Talacker 50
> > > > > 8001 Zurich, Switzerland
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > > For further information, visit:
> > > > > https://activemq.apache.org/contact
> > > > >
> > > > >
> > > > >
> > >
> > > --
> > > Dr.-Ing. Thorsten Meinl
> > > KNIME AG
> > > Talacker 50
> > > 8001 Zurich, Switzerland
> > >
> > >
> > > -------------------------------------------------------------------
> > > --
> > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > For additional commands, e-mail: users-help@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
> > >
> > >
>
> --
> Dr.-Ing. Thorsten Meinl
> KNIME AG
> Talacker 50
> 8001 Zurich, Switzerland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: Potential memory leak in Artemis JMS client

Posted by Thorsten Meinl <th...@knime.com>.
Am Donnerstag, dem 09.10.2025 um 12:08 -0500 schrieb Justin Bertram:
> > Shall I open a Jira issue for the issue?
> Yes.
Here it is: https://issues.apache.org/jira/browse/ARTEMIS-5699

> FYI - I sent an email to the Johnzon dev list [1] to inquire about
> getting
> a 1.2.x release with this fix.
Thanks for following up!

Cheers,

Thorsten

> On Thu, Oct 9, 2025 at 6:18 AM Thorsten Meinl
> <th...@knime.com>
> wrote:
> 
> > I have re-implemented the three methods that extract the response
> > data
> > from from management messages using a different Json parser. The
> > memory
> > leak is gone now.
> > 
> > Shall I open a Jira issue for the issue?
> > 
> > Thorsten
> > 
> > Am Mittwoch, dem 08.10.2025 um 11:30 -0500 schrieb Justin Bertram:
> > > The fix for this issue is actually on the branch for 1.2.x [1],
> > > but
> > > there
> > > hasn't been a 1.2 release to include it.
> > > 
> > > I was under the impression that the current javax branch (i.e.
> > > for
> > > 1.2.x)
> > > and the jakarta branch (i.e. for 2.x) would be maintained in
> > > parallel. I'll
> > > have to dig around and probably get in touch with the Johnzon
> > > developers to
> > > get to the bottom of this.
> > > 
> > > 
> > > Justin
> > > 
> > > [1]
> > > 
> > https://github.com/apache/johnzon/commit/664cb73f629fd0190902a0f1080c420a509e66b0
> > > 
> > > On Wed, Oct 8, 2025 at 9:59 AM Thorsten Meinl
> > > <th...@knime.com>
> > > wrote:
> > > 
> > > > I found it: it's
> > > > https://issues.apache.org/jira/browse/JOHNZON-396
> > > > It's fixed in version 2.0.1 but since Artemis is shading the
> > > > old
> > > > version 1.21 the bug is still present. It affects all responses
> > > > from
> > > > the broker that contain a string larger than ~200kB. In our
> > > > case a
> > > > list
> > > > of around 4,400 addresses.
> > > > 
> > > > Is there a way to access the value in the response without
> > > > using
> > > > the
> > > > buggy JSON parser?
> > > > 
> > > > Thorsten
> > > > 
> > > > Am Dienstag, dem 07.10.2025 um 15:17 -0500 schrieb Justin
> > > > Bertram:
> > > > > Are you doing anything else with JMS and/or Artemis-specific
> > > > > code
> > > > > in
> > > > > your
> > > > > application other than this snippet you pasted?
> > > > > 
> > > > > Unfortunately I don't have any hunches about what the problem
> > > > > might
> > > > > be.
> > > > > This code has been in place for years and this is the first
> > > > > time
> > > > > I
> > > > > can
> > > > > recall ever seeing any kind of issue with it - memory or
> > > > > otherwise. I
> > > > > was
> > > > > hoping to get some clues about the problem based on a more
> > > > > detailed
> > > > > description of your use-case. It would be helpful to
> > > > > understand
> > > > > everything
> > > > > your application is doing with JMS and any Artemis-specific
> > > > > implementation
> > > > > classes.
> > > > > 
> > > > > 
> > > > > Justin
> > > > > 
> > > > > On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl
> > > > > <th...@knime.com>
> > > > > wrote:
> > > > > 
> > > > > > Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin
> > > > > > Bertram:
> > > > > > > The image indicates there's accumulation related to JSON
> > > > > > > parsing
> > > > > > > which I
> > > > > > > wouldn't expect during the normal process of consuming a
> > > > > > > message.
> > > > > > > 
> > > > > > > Can you share any more details about your use-case?
> > > > > > Not sure what details you need, but we access the message
> > > > > > body
> > > > > > with
> > > > > > getBody(byte[].class) as well as some string properties. We
> > > > > > also
> > > > > > send
> > > > > > very similar messages from the same application (also with
> > > > > > a
> > > > > > byte[]
> > > > > > body) inside the same transaction. Afterwards the JMS
> > > > > > context
> > > > > > is
> > > > > > committed. And then it repeats.
> > > > > > 
> > > > > > > Do you have a reproducer?
> > > > > > Not yet, I can work on one.
> > > > > > 
> > > > > > >  Are the client and the broker in the same JVM?
> > > > > > No.
> > > > > > 
> > > > > > Do you have any suspicion where to look closer? I am happy
> > > > > > to
> > > > > > debug
> > > > > > myself if I get some pointers. This might be easier than
> > > > > > stripping
> > > > > > everything down to a minimal reproducer.
> > > > > > 
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > > Thorsten
> > > > > > 
> > > > > > 
> > > > > > > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> > > > > > > <th...@knime.com>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > Bummer. I hope this works:
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > 
> > https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > > > > > > > 
> > > > > > > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb
> > > > > > > > Justin
> > > > > > > > Bertram:
> > > > > > > > > I believe your attachment was stripped by the mailing
> > > > > > > > > list.
> > > > > > > > > Could
> > > > > > > > > you
> > > > > > > > > provide a link to it?
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Justin
> > > > > > > > > 
> > > > > > > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > > > > > > > <th...@knime.com>
> > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > We are using the Artemis JMS client 2.42.0 in an
> > > > > > > > > > application
> > > > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > following pattern:
> > > > > > > > > > 
> > > > > > > > > > try (var context =
> > > > > > > > > > connectionFactory.createContext(Session.SESSION_TRA
> > > > > > > > > > NSAC
> > > > > > > > > > TED)
> > > > > > > > > > ;
> > > > > > > > > >     var consumer =
> > > > > > > > > > context.createSharedDurableConsumer(topic,
> > > > > > > > > > queueName, QUEUE_FILTER)) {
> > > > > > > > > >      while
> > > > > > > > > > (!Thread.currentThread().isInterrupted()) {
> > > > > > > > > >         var message = consumer.receive();
> > > > > > > > > >         if (message == null) {
> > > > > > > > > >              break;
> > > > > > > > > >         }
> > > > > > > > > >         // do some stuff
> > > > > > > > > >         context.commit();
> > > > > > > > > >     }
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > The service regularly runs out of memory after some
> > > > > > > > > > time.
> > > > > > > > > > We
> > > > > > > > > > created a
> > > > > > > > > > heap dump and found some data structures deep in
> > > > > > > > > > the
> > > > > > > > > > Artemis
> > > > > > > > > > client
> > > > > > > > > > of
> > > > > > > > > > more than 500MB while our messages are are in
> > > > > > > > > > almost
> > > > > > > > > > all
> > > > > > > > > > cases
> > > > > > > > > > below
> > > > > > > > > > 1MB in some exceptional cases up to 20MB. I have
> > > > > > > > > > attached a
> > > > > > > > > > snippet
> > > > > > > > > > of
> > > > > > > > > > the heap dump.
> > > > > > > > > > Is this an issue in the client code or are we doing
> > > > > > > > > > something
> > > > > > > > > > wrong
> > > > > > > > > > in
> > > > > > > > > > our application code?
> > > > > > > > > > 
> > > > > > > > > > Thanks,
> > > > > > > > > > 
> > > > > > > > > > Thorsten
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > > > > KNIME AG
> > > > > > > > > > Talacker 50
> > > > > > > > > > 8001 Zurich, Switzerland
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ---------------------------------------------------
> > > > > > > > > > ----
> > > > > > > > > > ----
> > > > > > > > > > ----
> > > > > > > > > > ----
> > > > > > > > > > --
> > > > > > > > > > To unsubscribe, e-mail:
> > > > > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > > > > For additional commands, e-mail:
> > > > > > > > > > users-help@activemq.apache.org
> > > > > > > > > > For further information, visit:
> > > > > > > > > > https://activemq.apache.org/contact
> > > > > > > > > > 
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > > KNIME AG
> > > > > > > > Talacker 50
> > > > > > > > 8001 Zurich, Switzerland
> > > > > > > > 
> > > > > > > > 
> > > > > > > > -------------------------------------------------------
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > --
> > > > > > > > To unsubscribe, e-mail:
> > > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > > For additional commands, e-mail:
> > > > > > > > users-help@activemq.apache.org
> > > > > > > > For further information, visit:
> > > > > > > > https://activemq.apache.org/contact
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > KNIME AG
> > > > > > Talacker 50
> > > > > > 8001 Zurich, Switzerland
> > > > > > 
> > > > > > 
> > > > > > -----------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > users-unsubscribe@activemq.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > users-help@activemq.apache.org
> > > > > > For further information, visit:
> > > > > > https://activemq.apache.org/contact
> > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > --
> > > > Dr.-Ing. Thorsten Meinl
> > > > KNIME AG
> > > > Talacker 50
> > > > 8001 Zurich, Switzerland
> > > > 
> > > > 
> > > > ---------------------------------------------------------------
> > > > ----
> > > > --
> > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > For further information, visit:
> > > > https://activemq.apache.org/contact
> > > > 
> > > > 
> > > > 
> > 
> > --
> > Dr.-Ing. Thorsten Meinl
> > KNIME AG
> > Talacker 50
> > 8001 Zurich, Switzerland
> > 
> > 
> > -------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: users-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> > 
> > 
> > 

-- 
Dr.-Ing. Thorsten Meinl
KNIME AG
Talacker 50
8001 Zurich, Switzerland


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Potential memory leak in Artemis JMS client

Posted by Justin Bertram <jb...@apache.org>.
> Shall I open a Jira issue for the issue?

Yes.

FYI - I sent an email to the Johnzon dev list [1] to inquire about getting
a 1.2.x release with this fix.


Justin

[1] https://lists.apache.org/thread/2mh53568t5wttzn86ytxyqm215yprqnc

On Thu, Oct 9, 2025 at 6:18 AM Thorsten Meinl <th...@knime.com>
wrote:

> I have re-implemented the three methods that extract the response data
> from from management messages using a different Json parser. The memory
> leak is gone now.
>
> Shall I open a Jira issue for the issue?
>
> Thorsten
>
> Am Mittwoch, dem 08.10.2025 um 11:30 -0500 schrieb Justin Bertram:
> > The fix for this issue is actually on the branch for 1.2.x [1], but
> > there
> > hasn't been a 1.2 release to include it.
> >
> > I was under the impression that the current javax branch (i.e. for
> > 1.2.x)
> > and the jakarta branch (i.e. for 2.x) would be maintained in
> > parallel. I'll
> > have to dig around and probably get in touch with the Johnzon
> > developers to
> > get to the bottom of this.
> >
> >
> > Justin
> >
> > [1]
> >
> https://github.com/apache/johnzon/commit/664cb73f629fd0190902a0f1080c420a509e66b0
> >
> > On Wed, Oct 8, 2025 at 9:59 AM Thorsten Meinl
> > <th...@knime.com>
> > wrote:
> >
> > > I found it: it's https://issues.apache.org/jira/browse/JOHNZON-396
> > > It's fixed in version 2.0.1 but since Artemis is shading the old
> > > version 1.21 the bug is still present. It affects all responses
> > > from
> > > the broker that contain a string larger than ~200kB. In our case a
> > > list
> > > of around 4,400 addresses.
> > >
> > > Is there a way to access the value in the response without using
> > > the
> > > buggy JSON parser?
> > >
> > > Thorsten
> > >
> > > Am Dienstag, dem 07.10.2025 um 15:17 -0500 schrieb Justin Bertram:
> > > > Are you doing anything else with JMS and/or Artemis-specific code
> > > > in
> > > > your
> > > > application other than this snippet you pasted?
> > > >
> > > > Unfortunately I don't have any hunches about what the problem
> > > > might
> > > > be.
> > > > This code has been in place for years and this is the first time
> > > > I
> > > > can
> > > > recall ever seeing any kind of issue with it - memory or
> > > > otherwise. I
> > > > was
> > > > hoping to get some clues about the problem based on a more
> > > > detailed
> > > > description of your use-case. It would be helpful to understand
> > > > everything
> > > > your application is doing with JMS and any Artemis-specific
> > > > implementation
> > > > classes.
> > > >
> > > >
> > > > Justin
> > > >
> > > > On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl
> > > > <th...@knime.com>
> > > > wrote:
> > > >
> > > > > Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin
> > > > > Bertram:
> > > > > > The image indicates there's accumulation related to JSON
> > > > > > parsing
> > > > > > which I
> > > > > > wouldn't expect during the normal process of consuming a
> > > > > > message.
> > > > > >
> > > > > > Can you share any more details about your use-case?
> > > > > Not sure what details you need, but we access the message body
> > > > > with
> > > > > getBody(byte[].class) as well as some string properties. We
> > > > > also
> > > > > send
> > > > > very similar messages from the same application (also with a
> > > > > byte[]
> > > > > body) inside the same transaction. Afterwards the JMS context
> > > > > is
> > > > > committed. And then it repeats.
> > > > >
> > > > > > Do you have a reproducer?
> > > > > Not yet, I can work on one.
> > > > >
> > > > > >  Are the client and the broker in the same JVM?
> > > > > No.
> > > > >
> > > > > Do you have any suspicion where to look closer? I am happy to
> > > > > debug
> > > > > myself if I get some pointers. This might be easier than
> > > > > stripping
> > > > > everything down to a minimal reproducer.
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Thorsten
> > > > >
> > > > >
> > > > > > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> > > > > > <th...@knime.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Bummer. I hope this works:
> > > > > > >
> > > > > > >
> > > > >
> > >
> https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > > > > > >
> > > > > > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin
> > > > > > > Bertram:
> > > > > > > > I believe your attachment was stripped by the mailing
> > > > > > > > list.
> > > > > > > > Could
> > > > > > > > you
> > > > > > > > provide a link to it?
> > > > > > > >
> > > > > > > >
> > > > > > > > Justin
> > > > > > > >
> > > > > > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > > > > > > <th...@knime.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > We are using the Artemis JMS client 2.42.0 in an
> > > > > > > > > application
> > > > > > > > > with
> > > > > > > > > the
> > > > > > > > > following pattern:
> > > > > > > > >
> > > > > > > > > try (var context =
> > > > > > > > > connectionFactory.createContext(Session.SESSION_TRANSAC
> > > > > > > > > TED)
> > > > > > > > > ;
> > > > > > > > >     var consumer =
> > > > > > > > > context.createSharedDurableConsumer(topic,
> > > > > > > > > queueName, QUEUE_FILTER)) {
> > > > > > > > >      while (!Thread.currentThread().isInterrupted()) {
> > > > > > > > >         var message = consumer.receive();
> > > > > > > > >         if (message == null) {
> > > > > > > > >              break;
> > > > > > > > >         }
> > > > > > > > >         // do some stuff
> > > > > > > > >         context.commit();
> > > > > > > > >     }
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > The service regularly runs out of memory after some
> > > > > > > > > time.
> > > > > > > > > We
> > > > > > > > > created a
> > > > > > > > > heap dump and found some data structures deep in the
> > > > > > > > > Artemis
> > > > > > > > > client
> > > > > > > > > of
> > > > > > > > > more than 500MB while our messages are are in almost
> > > > > > > > > all
> > > > > > > > > cases
> > > > > > > > > below
> > > > > > > > > 1MB in some exceptional cases up to 20MB. I have
> > > > > > > > > attached a
> > > > > > > > > snippet
> > > > > > > > > of
> > > > > > > > > the heap dump.
> > > > > > > > > Is this an issue in the client code or are we doing
> > > > > > > > > something
> > > > > > > > > wrong
> > > > > > > > > in
> > > > > > > > > our application code?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > Thorsten
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > > > KNIME AG
> > > > > > > > > Talacker 50
> > > > > > > > > 8001 Zurich, Switzerland
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > -------------------------------------------------------
> > > > > > > > > ----
> > > > > > > > > ----
> > > > > > > > > ----
> > > > > > > > > --
> > > > > > > > > To unsubscribe, e-mail:
> > > > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > > > > > > > users-help@activemq.apache.org
> > > > > > > > > For further information, visit:
> > > > > > > > > https://activemq.apache.org/contact
> > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > KNIME AG
> > > > > > > Talacker 50
> > > > > > > 8001 Zurich, Switzerland
> > > > > > >
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > For additional commands, e-mail:
> > > > > > > users-help@activemq.apache.org
> > > > > > > For further information, visit:
> > > > > > > https://activemq.apache.org/contact
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Dr.-Ing. Thorsten Meinl
> > > > > KNIME AG
> > > > > Talacker 50
> > > > > 8001 Zurich, Switzerland
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > > For further information, visit:
> > > > > https://activemq.apache.org/contact
> > > > >
> > > > >
> > > > >
> > >
> > > --
> > > Dr.-Ing. Thorsten Meinl
> > > KNIME AG
> > > Talacker 50
> > > 8001 Zurich, Switzerland
> > >
> > >
> > > -------------------------------------------------------------------
> > > --
> > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > For additional commands, e-mail: users-help@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
> > >
> > >
>
> --
> Dr.-Ing. Thorsten Meinl
> KNIME AG
> Talacker 50
> 8001 Zurich, Switzerland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: Potential memory leak in Artemis JMS client

Posted by Thorsten Meinl <th...@knime.com>.
I have re-implemented the three methods that extract the response data
from from management messages using a different Json parser. The memory
leak is gone now.

Shall I open a Jira issue for the issue?

Thorsten

Am Mittwoch, dem 08.10.2025 um 11:30 -0500 schrieb Justin Bertram:
> The fix for this issue is actually on the branch for 1.2.x [1], but
> there
> hasn't been a 1.2 release to include it.
> 
> I was under the impression that the current javax branch (i.e. for
> 1.2.x)
> and the jakarta branch (i.e. for 2.x) would be maintained in
> parallel. I'll
> have to dig around and probably get in touch with the Johnzon
> developers to
> get to the bottom of this.
> 
> 
> Justin
> 
> [1]
> https://github.com/apache/johnzon/commit/664cb73f629fd0190902a0f1080c420a509e66b0
> 
> On Wed, Oct 8, 2025 at 9:59 AM Thorsten Meinl
> <th...@knime.com>
> wrote:
> 
> > I found it: it's https://issues.apache.org/jira/browse/JOHNZON-396
> > It's fixed in version 2.0.1 but since Artemis is shading the old
> > version 1.21 the bug is still present. It affects all responses
> > from
> > the broker that contain a string larger than ~200kB. In our case a
> > list
> > of around 4,400 addresses.
> > 
> > Is there a way to access the value in the response without using
> > the
> > buggy JSON parser?
> > 
> > Thorsten
> > 
> > Am Dienstag, dem 07.10.2025 um 15:17 -0500 schrieb Justin Bertram:
> > > Are you doing anything else with JMS and/or Artemis-specific code
> > > in
> > > your
> > > application other than this snippet you pasted?
> > > 
> > > Unfortunately I don't have any hunches about what the problem
> > > might
> > > be.
> > > This code has been in place for years and this is the first time
> > > I
> > > can
> > > recall ever seeing any kind of issue with it - memory or
> > > otherwise. I
> > > was
> > > hoping to get some clues about the problem based on a more
> > > detailed
> > > description of your use-case. It would be helpful to understand
> > > everything
> > > your application is doing with JMS and any Artemis-specific
> > > implementation
> > > classes.
> > > 
> > > 
> > > Justin
> > > 
> > > On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl
> > > <th...@knime.com>
> > > wrote:
> > > 
> > > > Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin
> > > > Bertram:
> > > > > The image indicates there's accumulation related to JSON
> > > > > parsing
> > > > > which I
> > > > > wouldn't expect during the normal process of consuming a
> > > > > message.
> > > > > 
> > > > > Can you share any more details about your use-case?
> > > > Not sure what details you need, but we access the message body
> > > > with
> > > > getBody(byte[].class) as well as some string properties. We
> > > > also
> > > > send
> > > > very similar messages from the same application (also with a
> > > > byte[]
> > > > body) inside the same transaction. Afterwards the JMS context
> > > > is
> > > > committed. And then it repeats.
> > > > 
> > > > > Do you have a reproducer?
> > > > Not yet, I can work on one.
> > > > 
> > > > >  Are the client and the broker in the same JVM?
> > > > No.
> > > > 
> > > > Do you have any suspicion where to look closer? I am happy to
> > > > debug
> > > > myself if I get some pointers. This might be easier than
> > > > stripping
> > > > everything down to a minimal reproducer.
> > > > 
> > > > 
> > > > Thanks,
> > > > 
> > > > Thorsten
> > > > 
> > > > 
> > > > > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> > > > > <th...@knime.com>
> > > > > wrote:
> > > > > 
> > > > > > Bummer. I hope this works:
> > > > > > 
> > > > > > 
> > > > 
> > https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > > > > > 
> > > > > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin
> > > > > > Bertram:
> > > > > > > I believe your attachment was stripped by the mailing
> > > > > > > list.
> > > > > > > Could
> > > > > > > you
> > > > > > > provide a link to it?
> > > > > > > 
> > > > > > > 
> > > > > > > Justin
> > > > > > > 
> > > > > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > > > > > <th...@knime.com>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > We are using the Artemis JMS client 2.42.0 in an
> > > > > > > > application
> > > > > > > > with
> > > > > > > > the
> > > > > > > > following pattern:
> > > > > > > > 
> > > > > > > > try (var context =
> > > > > > > > connectionFactory.createContext(Session.SESSION_TRANSAC
> > > > > > > > TED)
> > > > > > > > ;
> > > > > > > >     var consumer =
> > > > > > > > context.createSharedDurableConsumer(topic,
> > > > > > > > queueName, QUEUE_FILTER)) {
> > > > > > > >      while (!Thread.currentThread().isInterrupted()) {
> > > > > > > >         var message = consumer.receive();
> > > > > > > >         if (message == null) {
> > > > > > > >              break;
> > > > > > > >         }
> > > > > > > >         // do some stuff
> > > > > > > >         context.commit();
> > > > > > > >     }
> > > > > > > > }
> > > > > > > > 
> > > > > > > > The service regularly runs out of memory after some
> > > > > > > > time.
> > > > > > > > We
> > > > > > > > created a
> > > > > > > > heap dump and found some data structures deep in the
> > > > > > > > Artemis
> > > > > > > > client
> > > > > > > > of
> > > > > > > > more than 500MB while our messages are are in almost
> > > > > > > > all
> > > > > > > > cases
> > > > > > > > below
> > > > > > > > 1MB in some exceptional cases up to 20MB. I have
> > > > > > > > attached a
> > > > > > > > snippet
> > > > > > > > of
> > > > > > > > the heap dump.
> > > > > > > > Is this an issue in the client code or are we doing
> > > > > > > > something
> > > > > > > > wrong
> > > > > > > > in
> > > > > > > > our application code?
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > 
> > > > > > > > Thorsten
> > > > > > > > 
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > > KNIME AG
> > > > > > > > Talacker 50
> > > > > > > > 8001 Zurich, Switzerland
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > -------------------------------------------------------
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > ----
> > > > > > > > --
> > > > > > > > To unsubscribe, e-mail:
> > > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > > For additional commands, e-mail:
> > > > > > > > users-help@activemq.apache.org
> > > > > > > > For further information, visit:
> > > > > > > > https://activemq.apache.org/contact
> > > > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > KNIME AG
> > > > > > Talacker 50
> > > > > > 8001 Zurich, Switzerland
> > > > > > 
> > > > > > 
> > > > > > -----------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > users-unsubscribe@activemq.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > users-help@activemq.apache.org
> > > > > > For further information, visit:
> > > > > > https://activemq.apache.org/contact
> > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > --
> > > > Dr.-Ing. Thorsten Meinl
> > > > KNIME AG
> > > > Talacker 50
> > > > 8001 Zurich, Switzerland
> > > > 
> > > > 
> > > > ---------------------------------------------------------------
> > > > ----
> > > > --
> > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > For further information, visit:
> > > > https://activemq.apache.org/contact
> > > > 
> > > > 
> > > > 
> > 
> > --
> > Dr.-Ing. Thorsten Meinl
> > KNIME AG
> > Talacker 50
> > 8001 Zurich, Switzerland
> > 
> > 
> > -------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: users-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> > 
> > 
> > 

-- 
Dr.-Ing. Thorsten Meinl
KNIME AG
Talacker 50
8001 Zurich, Switzerland


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Potential memory leak in Artemis JMS client

Posted by Justin Bertram <jb...@apache.org>.
The fix for this issue is actually on the branch for 1.2.x [1], but there
hasn't been a 1.2 release to include it.

I was under the impression that the current javax branch (i.e. for 1.2.x)
and the jakarta branch (i.e. for 2.x) would be maintained in parallel. I'll
have to dig around and probably get in touch with the Johnzon developers to
get to the bottom of this.


Justin

[1]
https://github.com/apache/johnzon/commit/664cb73f629fd0190902a0f1080c420a509e66b0

On Wed, Oct 8, 2025 at 9:59 AM Thorsten Meinl <th...@knime.com>
wrote:

> I found it: it's https://issues.apache.org/jira/browse/JOHNZON-396
> It's fixed in version 2.0.1 but since Artemis is shading the old
> version 1.21 the bug is still present. It affects all responses from
> the broker that contain a string larger than ~200kB. In our case a list
> of around 4,400 addresses.
>
> Is there a way to access the value in the response without using the
> buggy JSON parser?
>
> Thorsten
>
> Am Dienstag, dem 07.10.2025 um 15:17 -0500 schrieb Justin Bertram:
> > Are you doing anything else with JMS and/or Artemis-specific code in
> > your
> > application other than this snippet you pasted?
> >
> > Unfortunately I don't have any hunches about what the problem might
> > be.
> > This code has been in place for years and this is the first time I
> > can
> > recall ever seeing any kind of issue with it - memory or otherwise. I
> > was
> > hoping to get some clues about the problem based on a more detailed
> > description of your use-case. It would be helpful to understand
> > everything
> > your application is doing with JMS and any Artemis-specific
> > implementation
> > classes.
> >
> >
> > Justin
> >
> > On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl
> > <th...@knime.com>
> > wrote:
> >
> > > Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin Bertram:
> > > > The image indicates there's accumulation related to JSON parsing
> > > > which I
> > > > wouldn't expect during the normal process of consuming a message.
> > > >
> > > > Can you share any more details about your use-case?
> > > Not sure what details you need, but we access the message body with
> > > getBody(byte[].class) as well as some string properties. We also
> > > send
> > > very similar messages from the same application (also with a byte[]
> > > body) inside the same transaction. Afterwards the JMS context is
> > > committed. And then it repeats.
> > >
> > > > Do you have a reproducer?
> > > Not yet, I can work on one.
> > >
> > > >  Are the client and the broker in the same JVM?
> > > No.
> > >
> > > Do you have any suspicion where to look closer? I am happy to debug
> > > myself if I get some pointers. This might be easier than stripping
> > > everything down to a minimal reproducer.
> > >
> > >
> > > Thanks,
> > >
> > > Thorsten
> > >
> > >
> > > > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> > > > <th...@knime.com>
> > > > wrote:
> > > >
> > > > > Bummer. I hope this works:
> > > > >
> > > > >
> > >
> https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > > > >
> > > > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin
> > > > > Bertram:
> > > > > > I believe your attachment was stripped by the mailing list.
> > > > > > Could
> > > > > > you
> > > > > > provide a link to it?
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > > > > <th...@knime.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > We are using the Artemis JMS client 2.42.0 in an
> > > > > > > application
> > > > > > > with
> > > > > > > the
> > > > > > > following pattern:
> > > > > > >
> > > > > > > try (var context =
> > > > > > > connectionFactory.createContext(Session.SESSION_TRANSACTED)
> > > > > > > ;
> > > > > > >     var consumer =
> > > > > > > context.createSharedDurableConsumer(topic,
> > > > > > > queueName, QUEUE_FILTER)) {
> > > > > > >      while (!Thread.currentThread().isInterrupted()) {
> > > > > > >         var message = consumer.receive();
> > > > > > >         if (message == null) {
> > > > > > >              break;
> > > > > > >         }
> > > > > > >         // do some stuff
> > > > > > >         context.commit();
> > > > > > >     }
> > > > > > > }
> > > > > > >
> > > > > > > The service regularly runs out of memory after some time.
> > > > > > > We
> > > > > > > created a
> > > > > > > heap dump and found some data structures deep in the
> > > > > > > Artemis
> > > > > > > client
> > > > > > > of
> > > > > > > more than 500MB while our messages are are in almost all
> > > > > > > cases
> > > > > > > below
> > > > > > > 1MB in some exceptional cases up to 20MB. I have attached a
> > > > > > > snippet
> > > > > > > of
> > > > > > > the heap dump.
> > > > > > > Is this an issue in the client code or are we doing
> > > > > > > something
> > > > > > > wrong
> > > > > > > in
> > > > > > > our application code?
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Thorsten
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > > KNIME AG
> > > > > > > Talacker 50
> > > > > > > 8001 Zurich, Switzerland
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > > users-unsubscribe@activemq.apache.org
> > > > > > > For additional commands, e-mail:
> > > > > > > users-help@activemq.apache.org
> > > > > > > For further information, visit:
> > > > > > > https://activemq.apache.org/contact
> > > > > > >
> > > > >
> > > > > --
> > > > > Dr.-Ing. Thorsten Meinl
> > > > > KNIME AG
> > > > > Talacker 50
> > > > > 8001 Zurich, Switzerland
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > > For further information, visit:
> > > > > https://activemq.apache.org/contact
> > > > >
> > > > >
> > > > >
> > >
> > > --
> > > Dr.-Ing. Thorsten Meinl
> > > KNIME AG
> > > Talacker 50
> > > 8001 Zurich, Switzerland
> > >
> > >
> > > -------------------------------------------------------------------
> > > --
> > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > For additional commands, e-mail: users-help@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
> > >
> > >
>
> --
> Dr.-Ing. Thorsten Meinl
> KNIME AG
> Talacker 50
> 8001 Zurich, Switzerland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: Potential memory leak in Artemis JMS client

Posted by Thorsten Meinl <th...@knime.com>.
I found it: it's https://issues.apache.org/jira/browse/JOHNZON-396
It's fixed in version 2.0.1 but since Artemis is shading the old
version 1.21 the bug is still present. It affects all responses from
the broker that contain a string larger than ~200kB. In our case a list
of around 4,400 addresses.

Is there a way to access the value in the response without using the
buggy JSON parser?

Thorsten

Am Dienstag, dem 07.10.2025 um 15:17 -0500 schrieb Justin Bertram:
> Are you doing anything else with JMS and/or Artemis-specific code in
> your
> application other than this snippet you pasted?
> 
> Unfortunately I don't have any hunches about what the problem might
> be.
> This code has been in place for years and this is the first time I
> can
> recall ever seeing any kind of issue with it - memory or otherwise. I
> was
> hoping to get some clues about the problem based on a more detailed
> description of your use-case. It would be helpful to understand
> everything
> your application is doing with JMS and any Artemis-specific
> implementation
> classes.
> 
> 
> Justin
> 
> On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl
> <th...@knime.com>
> wrote:
> 
> > Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin Bertram:
> > > The image indicates there's accumulation related to JSON parsing
> > > which I
> > > wouldn't expect during the normal process of consuming a message.
> > > 
> > > Can you share any more details about your use-case?
> > Not sure what details you need, but we access the message body with
> > getBody(byte[].class) as well as some string properties. We also
> > send
> > very similar messages from the same application (also with a byte[]
> > body) inside the same transaction. Afterwards the JMS context is
> > committed. And then it repeats.
> > 
> > > Do you have a reproducer?
> > Not yet, I can work on one.
> > 
> > >  Are the client and the broker in the same JVM?
> > No.
> > 
> > Do you have any suspicion where to look closer? I am happy to debug
> > myself if I get some pointers. This might be easier than stripping
> > everything down to a minimal reproducer.
> > 
> > 
> > Thanks,
> > 
> > Thorsten
> > 
> > 
> > > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> > > <th...@knime.com>
> > > wrote:
> > > 
> > > > Bummer. I hope this works:
> > > > 
> > > > 
> > https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > > > 
> > > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin
> > > > Bertram:
> > > > > I believe your attachment was stripped by the mailing list.
> > > > > Could
> > > > > you
> > > > > provide a link to it?
> > > > > 
> > > > > 
> > > > > Justin
> > > > > 
> > > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > > > <th...@knime.com>
> > > > > wrote:
> > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > We are using the Artemis JMS client 2.42.0 in an
> > > > > > application
> > > > > > with
> > > > > > the
> > > > > > following pattern:
> > > > > > 
> > > > > > try (var context =
> > > > > > connectionFactory.createContext(Session.SESSION_TRANSACTED)
> > > > > > ;
> > > > > >     var consumer =
> > > > > > context.createSharedDurableConsumer(topic,
> > > > > > queueName, QUEUE_FILTER)) {
> > > > > >      while (!Thread.currentThread().isInterrupted()) {
> > > > > >         var message = consumer.receive();
> > > > > >         if (message == null) {
> > > > > >              break;
> > > > > >         }
> > > > > >         // do some stuff
> > > > > >         context.commit();
> > > > > >     }
> > > > > > }
> > > > > > 
> > > > > > The service regularly runs out of memory after some time.
> > > > > > We
> > > > > > created a
> > > > > > heap dump and found some data structures deep in the
> > > > > > Artemis
> > > > > > client
> > > > > > of
> > > > > > more than 500MB while our messages are are in almost all
> > > > > > cases
> > > > > > below
> > > > > > 1MB in some exceptional cases up to 20MB. I have attached a
> > > > > > snippet
> > > > > > of
> > > > > > the heap dump.
> > > > > > Is this an issue in the client code or are we doing
> > > > > > something
> > > > > > wrong
> > > > > > in
> > > > > > our application code?
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > > Thorsten
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > KNIME AG
> > > > > > Talacker 50
> > > > > > 8001 Zurich, Switzerland
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > -----------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > users-unsubscribe@activemq.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > users-help@activemq.apache.org
> > > > > > For further information, visit:
> > > > > > https://activemq.apache.org/contact
> > > > > > 
> > > > 
> > > > --
> > > > Dr.-Ing. Thorsten Meinl
> > > > KNIME AG
> > > > Talacker 50
> > > > 8001 Zurich, Switzerland
> > > > 
> > > > 
> > > > ---------------------------------------------------------------
> > > > ----
> > > > --
> > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > For further information, visit:
> > > > https://activemq.apache.org/contact
> > > > 
> > > > 
> > > > 
> > 
> > --
> > Dr.-Ing. Thorsten Meinl
> > KNIME AG
> > Talacker 50
> > 8001 Zurich, Switzerland
> > 
> > 
> > -------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: users-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> > 
> > 
> > 

-- 
Dr.-Ing. Thorsten Meinl
KNIME AG
Talacker 50
8001 Zurich, Switzerland


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Potential memory leak in Artemis JMS client

Posted by Thorsten Meinl <th...@knime.com>.
I am one step further. The problem is not caused by the code snippet I
posted initially but by some other functionality in the service that
uses the management API. It looks as follow:

try (var context = m_connectionFactory.createContext()) {
  var managementQueue = context.createQueue("activemq.management");
  var repliesQueue = context.createTemporaryQueue();
  var producer = context.createProducer();

  try (var reader = context.createConsumer(repliesQueue)) {
    var msg = context.createMessage();
    JMSManagementHelper.putOperationInvocation(msg,
ResourceNames.BROKER, "listAddresses", ";");
    msg.setJMSReplyTo(repliesQueue);
    producer.send(managementQueue, msg);

    var reply = consumer.receive(10000);
    if (reply != null) {
       var addressList = (String)JMSManagementHelper.getResult(reply,
String.class);
    }
    ...

  }
}

The response contains many addresses, several thousands in some cases.
The code is run every 30s and it seems the leak is somewhere there. The
individual response is not the problem but the buffers used to read the
responses pile up. As you can (barely) see in the screenshot the buffer
contents repeat themselves and they are strings with address names.
I wasn't able to reproduce the leak outside a complete system yet.

Digging further but maybe this new information rings a bell.

Thanks,

Thorsten

Am Dienstag, dem 07.10.2025 um 15:17 -0500 schrieb Justin Bertram:
> Are you doing anything else with JMS and/or Artemis-specific code in
> your
> application other than this snippet you pasted?
> 
> Unfortunately I don't have any hunches about what the problem might
> be.
> This code has been in place for years and this is the first time I
> can
> recall ever seeing any kind of issue with it - memory or otherwise. I
> was
> hoping to get some clues about the problem based on a more detailed
> description of your use-case. It would be helpful to understand
> everything
> your application is doing with JMS and any Artemis-specific
> implementation
> classes.
> 
> 
> Justin
> 
> On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl
> <th...@knime.com>
> wrote:
> 
> > Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin Bertram:
> > > The image indicates there's accumulation related to JSON parsing
> > > which I
> > > wouldn't expect during the normal process of consuming a message.
> > > 
> > > Can you share any more details about your use-case?
> > Not sure what details you need, but we access the message body with
> > getBody(byte[].class) as well as some string properties. We also
> > send
> > very similar messages from the same application (also with a byte[]
> > body) inside the same transaction. Afterwards the JMS context is
> > committed. And then it repeats.
> > 
> > > Do you have a reproducer?
> > Not yet, I can work on one.
> > 
> > >  Are the client and the broker in the same JVM?
> > No.
> > 
> > Do you have any suspicion where to look closer? I am happy to debug
> > myself if I get some pointers. This might be easier than stripping
> > everything down to a minimal reproducer.
> > 
> > 
> > Thanks,
> > 
> > Thorsten
> > 
> > 
> > > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> > > <th...@knime.com>
> > > wrote:
> > > 
> > > > Bummer. I hope this works:
> > > > 
> > > > 
> > https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > > > 
> > > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin
> > > > Bertram:
> > > > > I believe your attachment was stripped by the mailing list.
> > > > > Could
> > > > > you
> > > > > provide a link to it?
> > > > > 
> > > > > 
> > > > > Justin
> > > > > 
> > > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > > > <th...@knime.com>
> > > > > wrote:
> > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > We are using the Artemis JMS client 2.42.0 in an
> > > > > > application
> > > > > > with
> > > > > > the
> > > > > > following pattern:
> > > > > > 
> > > > > > try (var context =
> > > > > > connectionFactory.createContext(Session.SESSION_TRANSACTED)
> > > > > > ;
> > > > > >     var consumer =
> > > > > > context.createSharedDurableConsumer(topic,
> > > > > > queueName, QUEUE_FILTER)) {
> > > > > >      while (!Thread.currentThread().isInterrupted()) {
> > > > > >         var message = consumer.receive();
> > > > > >         if (message == null) {
> > > > > >              break;
> > > > > >         }
> > > > > >         // do some stuff
> > > > > >         context.commit();
> > > > > >     }
> > > > > > }
> > > > > > 
> > > > > > The service regularly runs out of memory after some time.
> > > > > > We
> > > > > > created a
> > > > > > heap dump and found some data structures deep in the
> > > > > > Artemis
> > > > > > client
> > > > > > of
> > > > > > more than 500MB while our messages are are in almost all
> > > > > > cases
> > > > > > below
> > > > > > 1MB in some exceptional cases up to 20MB. I have attached a
> > > > > > snippet
> > > > > > of
> > > > > > the heap dump.
> > > > > > Is this an issue in the client code or are we doing
> > > > > > something
> > > > > > wrong
> > > > > > in
> > > > > > our application code?
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > > Thorsten
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > Dr.-Ing. Thorsten Meinl
> > > > > > KNIME AG
> > > > > > Talacker 50
> > > > > > 8001 Zurich, Switzerland
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > -----------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > > users-unsubscribe@activemq.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > users-help@activemq.apache.org
> > > > > > For further information, visit:
> > > > > > https://activemq.apache.org/contact
> > > > > > 
> > > > 
> > > > --
> > > > Dr.-Ing. Thorsten Meinl
> > > > KNIME AG
> > > > Talacker 50
> > > > 8001 Zurich, Switzerland
> > > > 
> > > > 
> > > > ---------------------------------------------------------------
> > > > ----
> > > > --
> > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > For further information, visit:
> > > > https://activemq.apache.org/contact
> > > > 
> > > > 
> > > > 
> > 
> > --
> > Dr.-Ing. Thorsten Meinl
> > KNIME AG
> > Talacker 50
> > 8001 Zurich, Switzerland
> > 
> > 
> > -------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: users-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> > 
> > 
> > 

-- 
Dr.-Ing. Thorsten Meinl
KNIME AG
Talacker 50
8001 Zurich, Switzerland


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Potential memory leak in Artemis JMS client

Posted by Justin Bertram <jb...@apache.org>.
Are you doing anything else with JMS and/or Artemis-specific code in your
application other than this snippet you pasted?

Unfortunately I don't have any hunches about what the problem might be.
This code has been in place for years and this is the first time I can
recall ever seeing any kind of issue with it - memory or otherwise. I was
hoping to get some clues about the problem based on a more detailed
description of your use-case. It would be helpful to understand everything
your application is doing with JMS and any Artemis-specific implementation
classes.


Justin

On Tue, Oct 7, 2025 at 2:45 PM Thorsten Meinl <th...@knime.com>
wrote:

> Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin Bertram:
> > The image indicates there's accumulation related to JSON parsing
> > which I
> > wouldn't expect during the normal process of consuming a message.
> >
> > Can you share any more details about your use-case?
> Not sure what details you need, but we access the message body with
> getBody(byte[].class) as well as some string properties. We also send
> very similar messages from the same application (also with a byte[]
> body) inside the same transaction. Afterwards the JMS context is
> committed. And then it repeats.
>
> > Do you have a reproducer?
> Not yet, I can work on one.
>
> >  Are the client and the broker in the same JVM?
> No.
>
> Do you have any suspicion where to look closer? I am happy to debug
> myself if I get some pointers. This might be easier than stripping
> everything down to a minimal reproducer.
>
>
> Thanks,
>
> Thorsten
>
>
> > On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> > <th...@knime.com>
> > wrote:
> >
> > > Bummer. I hope this works:
> > >
> > >
> https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > >
> > > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin Bertram:
> > > > I believe your attachment was stripped by the mailing list. Could
> > > > you
> > > > provide a link to it?
> > > >
> > > >
> > > > Justin
> > > >
> > > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > > <th...@knime.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > We are using the Artemis JMS client 2.42.0 in an application
> > > > > with
> > > > > the
> > > > > following pattern:
> > > > >
> > > > > try (var context =
> > > > > connectionFactory.createContext(Session.SESSION_TRANSACTED);
> > > > >     var consumer = context.createSharedDurableConsumer(topic,
> > > > > queueName, QUEUE_FILTER)) {
> > > > >      while (!Thread.currentThread().isInterrupted()) {
> > > > >         var message = consumer.receive();
> > > > >         if (message == null) {
> > > > >              break;
> > > > >         }
> > > > >         // do some stuff
> > > > >         context.commit();
> > > > >     }
> > > > > }
> > > > >
> > > > > The service regularly runs out of memory after some time. We
> > > > > created a
> > > > > heap dump and found some data structures deep in the Artemis
> > > > > client
> > > > > of
> > > > > more than 500MB while our messages are are in almost all cases
> > > > > below
> > > > > 1MB in some exceptional cases up to 20MB. I have attached a
> > > > > snippet
> > > > > of
> > > > > the heap dump.
> > > > > Is this an issue in the client code or are we doing something
> > > > > wrong
> > > > > in
> > > > > our application code?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Thorsten
> > > > >
> > > > >
> > > > > --
> > > > > Dr.-Ing. Thorsten Meinl
> > > > > KNIME AG
> > > > > Talacker 50
> > > > > 8001 Zurich, Switzerland
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> > > > > ----
> > > > > --
> > > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > > For further information, visit:
> > > > > https://activemq.apache.org/contact
> > > > >
> > >
> > > --
> > > Dr.-Ing. Thorsten Meinl
> > > KNIME AG
> > > Talacker 50
> > > 8001 Zurich, Switzerland
> > >
> > >
> > > -------------------------------------------------------------------
> > > --
> > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > For additional commands, e-mail: users-help@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
> > >
> > >
>
> --
> Dr.-Ing. Thorsten Meinl
> KNIME AG
> Talacker 50
> 8001 Zurich, Switzerland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: Potential memory leak in Artemis JMS client

Posted by Thorsten Meinl <th...@knime.com>.
Am Dienstag, dem 07.10.2025 um 11:12 -0500 schrieb Justin Bertram:
> The image indicates there's accumulation related to JSON parsing
> which I
> wouldn't expect during the normal process of consuming a message.
> 
> Can you share any more details about your use-case? 
Not sure what details you need, but we access the message body with
getBody(byte[].class) as well as some string properties. We also send
very similar messages from the same application (also with a byte[]
body) inside the same transaction. Afterwards the JMS context is
committed. And then it repeats.

> Do you have a reproducer?
Not yet, I can work on one.

>  Are the client and the broker in the same JVM?
No.

Do you have any suspicion where to look closer? I am happy to debug
myself if I get some pointers. This might be easier than stripping
everything down to a minimal reproducer.


Thanks,

Thorsten


> On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl
> <th...@knime.com>
> wrote:
> 
> > Bummer. I hope this works:
> > 
> > https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
> > 
> > Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin Bertram:
> > > I believe your attachment was stripped by the mailing list. Could
> > > you
> > > provide a link to it?
> > > 
> > > 
> > > Justin
> > > 
> > > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > > <th...@knime.com>
> > > wrote:
> > > 
> > > > Hi,
> > > > 
> > > > We are using the Artemis JMS client 2.42.0 in an application
> > > > with
> > > > the
> > > > following pattern:
> > > > 
> > > > try (var context =
> > > > connectionFactory.createContext(Session.SESSION_TRANSACTED);
> > > >     var consumer = context.createSharedDurableConsumer(topic,
> > > > queueName, QUEUE_FILTER)) {
> > > >      while (!Thread.currentThread().isInterrupted()) {
> > > >         var message = consumer.receive();
> > > >         if (message == null) {
> > > >              break;
> > > >         }
> > > >         // do some stuff
> > > >         context.commit();
> > > >     }
> > > > }
> > > > 
> > > > The service regularly runs out of memory after some time. We
> > > > created a
> > > > heap dump and found some data structures deep in the Artemis
> > > > client
> > > > of
> > > > more than 500MB while our messages are are in almost all cases
> > > > below
> > > > 1MB in some exceptional cases up to 20MB. I have attached a
> > > > snippet
> > > > of
> > > > the heap dump.
> > > > Is this an issue in the client code or are we doing something
> > > > wrong
> > > > in
> > > > our application code?
> > > > 
> > > > Thanks,
> > > > 
> > > > Thorsten
> > > > 
> > > > 
> > > > --
> > > > Dr.-Ing. Thorsten Meinl
> > > > KNIME AG
> > > > Talacker 50
> > > > 8001 Zurich, Switzerland
> > > > 
> > > > 
> > > > 
> > > > ---------------------------------------------------------------
> > > > ----
> > > > --
> > > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > > For additional commands, e-mail: users-help@activemq.apache.org
> > > > For further information, visit:
> > > > https://activemq.apache.org/contact
> > > > 
> > 
> > --
> > Dr.-Ing. Thorsten Meinl
> > KNIME AG
> > Talacker 50
> > 8001 Zurich, Switzerland
> > 
> > 
> > -------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: users-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> > 
> > 
> > 

-- 
Dr.-Ing. Thorsten Meinl
KNIME AG
Talacker 50
8001 Zurich, Switzerland


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Potential memory leak in Artemis JMS client

Posted by Justin Bertram <jb...@apache.org>.
The image indicates there's accumulation related to JSON parsing which I
wouldn't expect during the normal process of consuming a message.

Can you share any more details about your use-case? Do you have a
reproducer? Are the client and the broker in the same JVM?


Justin

On Tue, Oct 7, 2025 at 10:53 AM Thorsten Meinl <th...@knime.com>
wrote:

> Bummer. I hope this works:
>
> https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing
>
> Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin Bertram:
> > I believe your attachment was stripped by the mailing list. Could you
> > provide a link to it?
> >
> >
> > Justin
> >
> > On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> > <th...@knime.com>
> > wrote:
> >
> > > Hi,
> > >
> > > We are using the Artemis JMS client 2.42.0 in an application with
> > > the
> > > following pattern:
> > >
> > > try (var context =
> > > connectionFactory.createContext(Session.SESSION_TRANSACTED);
> > >     var consumer = context.createSharedDurableConsumer(topic,
> > > queueName, QUEUE_FILTER)) {
> > >      while (!Thread.currentThread().isInterrupted()) {
> > >         var message = consumer.receive();
> > >         if (message == null) {
> > >              break;
> > >         }
> > >         // do some stuff
> > >         context.commit();
> > >     }
> > > }
> > >
> > > The service regularly runs out of memory after some time. We
> > > created a
> > > heap dump and found some data structures deep in the Artemis client
> > > of
> > > more than 500MB while our messages are are in almost all cases
> > > below
> > > 1MB in some exceptional cases up to 20MB. I have attached a snippet
> > > of
> > > the heap dump.
> > > Is this an issue in the client code or are we doing something wrong
> > > in
> > > our application code?
> > >
> > > Thanks,
> > >
> > > Thorsten
> > >
> > >
> > > --
> > > Dr.-Ing. Thorsten Meinl
> > > KNIME AG
> > > Talacker 50
> > > 8001 Zurich, Switzerland
> > >
> > >
> > >
> > > -------------------------------------------------------------------
> > > --
> > > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > > For additional commands, e-mail: users-help@activemq.apache.org
> > > For further information, visit: https://activemq.apache.org/contact
> > >
>
> --
> Dr.-Ing. Thorsten Meinl
> KNIME AG
> Talacker 50
> 8001 Zurich, Switzerland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>

Re: Potential memory leak in Artemis JMS client

Posted by Thorsten Meinl <th...@knime.com>.
Bummer. I hope this works:
https://drive.google.com/file/d/1U7wLYGDibiJi08_egHLnRxeEcDPSZgT9/view?usp=sharing

Am Dienstag, dem 07.10.2025 um 10:47 -0500 schrieb Justin Bertram:
> I believe your attachment was stripped by the mailing list. Could you
> provide a link to it?
> 
> 
> Justin
> 
> On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl
> <th...@knime.com>
> wrote:
> 
> > Hi,
> > 
> > We are using the Artemis JMS client 2.42.0 in an application with
> > the
> > following pattern:
> > 
> > try (var context =
> > connectionFactory.createContext(Session.SESSION_TRANSACTED);
> >     var consumer = context.createSharedDurableConsumer(topic,
> > queueName, QUEUE_FILTER)) {
> >      while (!Thread.currentThread().isInterrupted()) {
> >         var message = consumer.receive();
> >         if (message == null) {
> >              break;
> >         }
> >         // do some stuff
> >         context.commit();
> >     }
> > }
> > 
> > The service regularly runs out of memory after some time. We
> > created a
> > heap dump and found some data structures deep in the Artemis client
> > of
> > more than 500MB while our messages are are in almost all cases
> > below
> > 1MB in some exceptional cases up to 20MB. I have attached a snippet
> > of
> > the heap dump.
> > Is this an issue in the client code or are we doing something wrong
> > in
> > our application code?
> > 
> > Thanks,
> > 
> > Thorsten
> > 
> > 
> > --
> > Dr.-Ing. Thorsten Meinl
> > KNIME AG
> > Talacker 50
> > 8001 Zurich, Switzerland
> > 
> > 
> > 
> > -------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> > For additional commands, e-mail: users-help@activemq.apache.org
> > For further information, visit: https://activemq.apache.org/contact
> > 

-- 
Dr.-Ing. Thorsten Meinl
KNIME AG
Talacker 50
8001 Zurich, Switzerland


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: Potential memory leak in Artemis JMS client

Posted by Justin Bertram <jb...@apache.org>.
I believe your attachment was stripped by the mailing list. Could you
provide a link to it?


Justin

On Tue, Oct 7, 2025 at 10:38 AM Thorsten Meinl <th...@knime.com>
wrote:

> Hi,
>
> We are using the Artemis JMS client 2.42.0 in an application with the
> following pattern:
>
> try (var context =
> connectionFactory.createContext(Session.SESSION_TRANSACTED);
>     var consumer = context.createSharedDurableConsumer(topic,
> queueName, QUEUE_FILTER)) {
>      while (!Thread.currentThread().isInterrupted()) {
>         var message = consumer.receive();
>         if (message == null) {
>              break;
>         }
>         // do some stuff
>         context.commit();
>     }
> }
>
> The service regularly runs out of memory after some time. We created a
> heap dump and found some data structures deep in the Artemis client of
> more than 500MB while our messages are are in almost all cases below
> 1MB in some exceptional cases up to 20MB. I have attached a snippet of
> the heap dump.
> Is this an issue in the client code or are we doing something wrong in
> our application code?
>
> Thanks,
>
> Thorsten
>
>
> --
> Dr.-Ing. Thorsten Meinl
> KNIME AG
> Talacker 50
> 8001 Zurich, Switzerland
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>