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 > <[email protected]> > 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 > > > <[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_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: > > > > > > > > [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 > > > > > > -- 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
