You are right that I can define a more specific address-setting for the
$.artemis.internal, I was using the doc for 2.19.0 which is the broker
version I am using and it was not clear about how the address-settings
apply if there are multiple matches but i see it explain well in the latest
doc.
On a different note, the 2 ring queue
$.artemis.internal.{myAddress}.queue.multicast.retro and
$.artemis.internal.{myAddress}.queue.anycast.retro created by the broker
are connected to the $.artemis.internal.{myAddress}.address.retro address
and their consumers would be all the queues in myAddress address right ?
Thus i should not set auto-delete-queues for the
$.artemis.internal.{myAddress}.address.retro address otherwise when no
subscriber is subscribed to myAddress the 2 ring queues above are lost and
the retroactive configuration is broken.
Here is my address-settings:
<address-settings>
<address-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<redistribution-delay>60000</redistribution-delay>
<redelivery-delay>0</redelivery-delay>
<!-- with -1 only the global-max-size is in use for limiting -->
<max-size-bytes>-1</max-size-bytes>
<message-counter-history-day-limit>10</message-counter-history-day-limit>
<address-full-policy>PAGE</address-full-policy>
<auto-create-queues>true</auto-create-queues>
<auto-create-addresses>true</auto-create-addresses>
<auto-create-jms-queues>true</auto-create-jms-queues>
<auto-create-jms-topics>true</auto-create-jms-topics>
<auto-delete-queues>false</auto-delete-queues>
<auto-delete-jms-queues>false</auto-delete-jms-queues>
<default-consumer-window-size>0</default-consumer-window-size>
</address-setting>
<address-setting match="TOPIC.#">
<retroactive-message-count>1</retroactive-message-count>
<auto-delete-queues>true</auto-delete-queues>
<auto-delete-queues-delay>0</auto-delete-queues-delay>
<auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
</address-setting>
<address-setting match="$.artemis.internal.#.address.retro">
<auto-delete-queues>false</auto-delete-queues> <!-- because there are 2
ring queues connect to this address? -->
<auto-delete-addresses>true</auto-delete-addresses>
</address-setting>
</address-settings>
Thanks
Thai Le
On Wed, 29 Mar 2023 at 12:31, Justin Bertram <jbert...@apache.org> wrote:
> Any address-setting specified with match="#" will apply to the internal
> retroactive resources. Typically this isn't a problem. Do you expect this
> will be a problem in your case? If so, why?
>
> There is no "negative" address matching to match some and ignore others.
> You can just have your normal match="#" and then have another set of
> address-settings using match="$.artemis.internal.#" with the settings
> appropriate for your use-case.
>
>
> Justin
>
> On Wed, Mar 29, 2023 at 11:09 AM Thai Le <lnthai2...@gmail.com> wrote:
>
> > 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
> >
>
--
Where there is will, there is a way
