Justin,
Thank you for your suggestion. Retroactive queue is indeed what I need.
However the document said that by enabling
retroactive-message-count on an address the broker will create an internal
address $.artemis.internal.{sourceAddress}.queue.multicast.retro (giving
that my source address is multicast). Would this internal address affected
by my configuration for <address-setting match=#> ? If it is, is there a
negative address matching to say: apply these settings for all addresses
except those started with $.artemis.internal.# ?Regards Thai Le On Sat, 25 Mar 2023 at 18:28, Justin Bertram <jbert...@apache.org> wrote: > Technically speaking, there is no way to configure a "topic" in broker.xml > at all. However, you can configure addresses, queues, and routing types - > the 3 components of the broker's addressing model which can support the > semantics of JMS topics. See the documentation [1] [2] for more information > on that. > > That said, if you want a *new* JMS topic subscriber to receive the last > message sent to the topic then you can configure a retroactive address [3] > with a retroactive-message-count of 1. > > Using a retroactive address means you shouldn't have to use a durable > subscription so your second question is really moot. However, if you really > wanted to clean up durable subscription queues you could use the > auto-delete-* settings we currently have. > > > Justin > > [1] > > https://activemq.apache.org/components/artemis/documentation/latest/address-model.html > [2] > > https://activemq.apache.org/components/artemis/documentation/latest/jms-core-mapping.html > [3] > > https://activemq.apache.org/components/artemis/documentation/latest/retroactive-addresses.html > > > On Sat, Mar 25, 2023 at 6:07 AM Thai Le <lnthai2...@gmail.com> wrote: > > > Hello, > > Is there a way to configure a topic in broker.xml so that > > 1. New subscriber can get the last message sent to the topic (like the > > stock value example), I assume this need last-value-queue=true and > > durable=true > > 2. When there is no consumer connect to the subscriber queue for x > minutes > > the subscriber queue should be auto deleted (subscription can't be > > terminated from consumer side because there is no guarantee that it can > > terminate gracefully). Durable=false seem to be a solution here > > As you can see, setting for durable seem to be conflicting for my use > > case. Is there a way to satisfy both 1 and 2? > > > > Regards > > Thai Le > > > -- Where there is will, there is a way
