You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Thai Le <ln...@gmail.com> on 2023/03/25 11:05:59 UTC
Topic config to auto delete queue when there is no consumer on the subscriber queue
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
Re: Topic config to auto delete queue when there is no consumer on the subscriber queue
Posted by Thai Le <ln...@gmail.com>.
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 <jb...@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 <ln...@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 <jb...@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 <ln...@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
Re: Topic config to auto delete queue when there is no consumer on the subscriber queue
Posted by Justin Bertram <jb...@apache.org>.
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 <ln...@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 <jb...@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 <ln...@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
>
Re: Topic config to auto delete queue when there is no consumer on the subscriber queue
Posted by Thai Le <ln...@gmail.com>.
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 <jb...@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 <ln...@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
Re: Topic config to auto delete queue when there is no consumer on the subscriber queue
Posted by Justin Bertram <jb...@apache.org>.
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 <ln...@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
>