Revisiting this briefly... There is also a setting to turn off the temporary destination tracking on the client.
The setting is watchTopicAdvisories - setting it to false will stop the client from trying to track the temporary destinations, and could eliminate the scenario reported here. It is listed on this page: https://activemq.apache.org/components/classic/documentation/advisory-message Here's full URL example from that page: tcp://localhost:61616?jms.watchTopicAdvisories=false Hope this helps. Art On Wed, Feb 19, 2025 at 10:52 PM Justin Bertram <jbert...@apache.org> wrote: > The issue here is related to advisory messages which are sent to the > OpenWire client to inform it about the state of the broker. By default the > OpenWire client expects to receive advisory messages about new temporary > queues which are created. However, the default "artemis" acceptor in > broker.xml uses supportAdvisory=false which means the OpenWire client won't > get the advisory message it expects, and therefore it thinks the temp queue > doesn't actually exist (i.e. it was deleted). The solution to this problem > is either to set supportAdvisory=true on the acceptor or to set > jms.watchTopicAdvisories=false on the URL for the OpenWire client. Either > of these solutions allows your project to work successfully. > > For what it's worth, this same issue was reported a few years back in Jira > [1]. > > > Justin > > [1] https://issues.apache.org/jira/browse/ARTEMIS-3382 > > On Wed, Feb 19, 2025 at 4:00 PM Justin Bertram <jbert...@apache.org> > wrote: > > > When attempting to reproduce the issue I neglected to use the included > > SimpleRequester class. I am able to successfully reproduce the issue > using > > it. > > > > I'm continuing to investigate. Sorry for any confusion! > > > > > > Justin > > > > On Wed, Feb 19, 2025 at 3:45 PM Justin Bertram <jbert...@apache.org> > > wrote: > > > >> At this point we can stay on the dev list for simplicity's sake. > >> > >> I pulled down your project [1] and after adding the Hawtbuf library to > >> the "lib" directory I was able to run it. This is what it printed: > >> > >> Attempt to create connection > >> Connection established. > >> Connection started. > >> Sessions created. > >> serving on:queue://this.is.a.test.queue > >> > >> Then I used the "artemis producer" command to send a JMS TextMessage > with > >> the reply-to set, e.g.: > >> > >> ./artemis producer --message-count 1 --destination > >> queue://this.is.a.test.queue --properties > >> [\{\"type\":\"string\",\"key\":\"JMSReplyTo\",\"value\":\"foo\"}] > --message > >> Foo123 > >> > >> This is what your SimpleServer printed at that point: > >> > >> Received request > >> Destination=queue://this.is.a.test.queue > >> ReplyDestination=queue://foo > >> Message=Foo123 > >> > >> So it appears to be working properly. I don't see any occurrence of > >> InvalidDestinationException. > >> > >> Do you have instructions that I can use to reproduce the > >> InvalidDestinationException? > >> > >> > >> Justin > >> > >> [1] https://github.com/MaximilianRieder/ArtemisOpenwireTempQueueIssue > >> > >> On Wed, Feb 19, 2025 at 10:48 AM <maximilian.rie...@systema.com> wrote: > >> > >>> Hello Justin, > >>> > >>> I`m sorry for the wrong mailing list. > >>> Should i close this and re-open in the correct one? > >>> > >>> I put a small demo for the issue here: > >>> https://github.com/MaximilianRieder/ArtemisOpenwireTempQueueIssue > >>> > >>> Kind regards > >>> Maximilian > >>> > >>> > >>> Von: "Justin Bertram" <jbert...@apache.org> > >>> An: dev@activemq.apache.org > >>> Datum: 02/14/2025 07:05 PM > >>> Betreff: [Ext] Re: Artemis Openwire temporary queue issue > >>> ------------------------------ > >>> > >>> > >>> > >>> Do you have a test-case you can share (e.g. via GitHub)? Something I > can > >>> just grab and run to reproduce the problem would be ideal, but even > just > >>> the bare code involved would be better than nothing. > >>> > >>> Also, in the future please direct questions like this to the ActiveMQ > >>> users > >>> list (i.e. us...@activemq.apache.org). This list (i.e. the dev list) > is > >>> meant for folks who are working directly on an ActiveMQ code-base. > >>> > >>> > >>> Justin > >>> > >>> On Fri, Feb 14, 2025 at 9:25 AM <maximilian.rie...@systema.com> wrote: > >>> > >>> > Hello community, > >>> > > >>> > we encountered a problem with temporary Queues when using Openwire > with > >>> > Artemis. > >>> > > >>> > Situation: > >>> > We want to use an Artemis broker with Applications communicating over > >>> > Openwire with JMS. > >>> > Specifically, we want to perform request reply using the reply-to > field > >>> > and temporary queues. > >>> > For the broker we have an Artemis broker (Version 2.37). > >>> > The clients use the ActiveMQ classic client libraries. > >>> > For the reply we create a temporary queue with: > >>> > org.apache.activemq.ActiveMQSession.createTemporaryQueue() > >>> > > >>> > First scenario: Temp queues working in same JVM: > >>> > We have a unit test where we send the request on a queue > >>> ("request-queue") > >>> > on the broker and create the temporary queue beforehand as described, > >>> to > >>> > receive the reply. > >>> > In the Unit test we also subscribe to that "request-queue" and if a > >>> > message is received we send a reply to the temporary queue (specified > >>> in > >>> > the JMS-reply-to field). > >>> > That works as we would expect and the reply is received on the > >>> temporary > >>> > queue. > >>> > > >>> > Second scenario: Temp queues not working in different JVMs: > >>> > Now for the part where we encounter the error. > >>> > We set up the same scenario as in one, but not in a unit test but > with > >>> two > >>> > different applications. > >>> > So one application with the activeMQ classic libraries that sets a > >>> > temporary queue, set the JMS-reply-to to that queue and send the > >>> message to > >>> > a queue ("request-queue") on the broker. > >>> > The second application subscribes to that "request-queue" and > receives > >>> the > >>> > message. > >>> > We extract the temporary reply queue with Destination > replyDestination > >>> = > >>> > msg.getJMSReplyTo(); > >>> > But when we want to send the message we encounter the following > error: > >>> > > >>> > javax.jms.InvalidDestinationException: Cannot publish to a deleted > >>> > Destination: temp-queue://ID:NTNB794-64640-1739355767427-5:1:1 > >>> > at > >>> > org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1841) > >>> > at > >>> > > >>> > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) > >>> > at > >>> > > >>> > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) > >>> > at > >>> > > >>> > de.systemagmbh.components.bus.activemq.CSysAMQServiceRunnerCallback.sendReply(CSysAMQServiceRunnerCallback.java) > >>> > at > >>> > > de.systemagmbh.tools.bus.CSysServiceRunner.run(CSysServiceRunner.java) > >>> > at > >>> > > >>> > de.systemagmbh.tools.bus.ASysServiceRunnerCallback.startServiceRunner(ASysServiceRunnerCallback.java) > >>> > at > >>> > > >>> > de.systemagmbh.components.bus.activemq.CSysAMQServiceRunnerCallback.<init>(CSysAMQServiceRunnerCallback.java) > >>> > at > >>> > > >>> > de.systemagmbh.components.bus.activemq.CSysAMQServiceSubjectDriver.onMessage(CSysAMQServiceSubjectDriver.java) > >>> > at > >>> > > >>> > org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1390) > >>> > at > >>> > > >>> > org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131) > >>> > at > >>> > > >>> > org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202) > >>> > at > >>> > > >>> > org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133) > >>> > at > >>> > > >>> > org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48) > >>> > at > >>> > > >>> > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) > >>> > at > >>> > > >>> > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) > >>> > at java.base/java.lang.Thread.run(Thread.java:1583) > >>> > > >>> > Have any of you encountered something similar or knows if we do > >>> something > >>> > wrong? > >>> > > >>> > Kind regards Maximilian > >>> > ------------------------------ > >>> > > >>> > *Maximilian Rieder* > >>> > Software Engineer > >>> > > >>> > Phone: +49 941 / 7 83 92 84 > >>> > maximilian.rie...@systema.com > >>> > > >>> > www.systema.com > >>> > > >>> > [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/ > >>> >[image: > >>> > Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: > >>> XING] > >>> > <https://www.xing.com/pages/systemagmbh> > >>> > > >>> > SYSTEMA > >>> > Systementwicklung Dipl.-Inf. Manfred Austen GmbH > >>> > > >>> > Manfred-von-Ardenne-Ring 6 | 01099 Dresden > >>> > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786 > >>> > Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO > >>> > > >>> > P Please check whether a printout of this e-mail is really necessary. > >>> > > >>> > >>> > >>> > >>> ------------------------------ > >>> > >>> *Maximilian Rieder* > >>> Software Engineer > >>> > >>> Phone: +49 941 / 7 83 92 84 > >>> maximilian.rie...@systema.com > >>> > >>> www.systema.com > >>> > >>> [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/ > >[image: > >>> Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: > XING] > >>> <https://www.xing.com/pages/systemagmbh> > >>> > >>> SYSTEMA > >>> Systementwicklung Dipl.-Inf. Manfred Austen GmbH > >>> > >>> Manfred-von-Ardenne-Ring 6 | 01099 Dresden > >>> HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786 > >>> Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO > >>> > >>> P Please check whether a printout of this e-mail is really necessary. > >>> > >> >
