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
> <[email protected]>
> 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
> > > <[email protected]>
> > > 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
> > > > > <[email protected]>
> > > > > 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:
> > > > > > [email protected]
> > > > > > For additional commands, e-mail:
> > > > > > [email protected]
> > > > > > For further information, visit:
> > > > > > https://activemq.apache.org/contact
> > > > > >
> > > >
> > > > --
> > > > Dr.-Ing. Thorsten Meinl
> > > > KNIME AG
> > > > Talacker 50
> > > > 8001 Zurich, Switzerland
> > > >
> > > >
> > > > ---------------------------------------------------------------
> > > > ----
> > > > --
> > > > To unsubscribe, e-mail: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > > For further information, visit:
> > > > https://activemq.apache.org/contact
> > > >
> > > >
> > > >
> >
> > --
> > Dr.-Ing. Thorsten Meinl
> > KNIME AG
> > Talacker 50
> > 8001 Zurich, Switzerland
> >
> >
> > -------------------------------------------------------------------
> > --
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > For further information, visit: https://activemq.apache.org/contact
> >
> >
> >
--
Dr.-Ing. Thorsten Meinl
KNIME AG
Talacker 50
8001 Zurich, Switzerland
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
