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