I attempted to answer this same question of yours on Stack Overflow [1].
Justin [1] https://stackoverflow.com/questions/51770006/apachemq-artemis-keep-messages-with-no-route/51773712#51773712 On Thu, Aug 9, 2018 at 9:38 AM, BS <[email protected]> wrote: > I am using Artemis 2.6.2 with STOMP only and the following constellation: > > Broker: > * No queues configured in broker.xml, everything is auto created. > > Server: > * SUBSCRIBE to destination "TaskResponse" without selector/filter > * SEND to destination "TaskRequest" with header clientId = ID (the ID of > the > client what the server would request to) > > Client 123: > * SUBSCRIBE to destination "TaskRequest" with selector clientId = 123 > * SEND to destination "TaskResponse" with header clientId = 123 > > When I watch at the Artemis Console the following happens: > > 1. No server and no client is connected > No address or queue is present > > 2. Server connect > Artemis creates a multicast address "TaskResponse" and a multicast queue > for > this address with empty filter > > 3. Client 123 connect > Artemis creates a multicast address "TaskRequest" and a multicast queue for > this address with filter clientId = 123 > > 4. Message exchange > Messages are transfered from server to client and back to server as > expected. > > 5. Client 123 disconnect > Artemis removes the multicast address "TaskRequest" and the coresponding > multicast queue with filter clientId = 123 > > 6. Server sends message to TaskRequest for client 123 > According to STOMP client on server the message is sent successful. > On the broker the message disappears. > > 7. Same behavior vice versa: Client 123 is connected and server is not > According to STOMP client on client 123 the message is sent successful. > On the broker the message disappears. > > My guess is that the message is discarded because there is no route to a > subscriber. If I enable the option "send-to-dla-on-no-route" in > address-settings section of broker.xml the message goes directly to dead > letter queue. > > Do you know a way to preserve the messages until the subscriber reconnects? > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
