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/04/18 16:19:34 UTC

offlineDurableSubscriberTimeout in artemis

Hello,
I would like to auto unsubscribe a durable subscription from a
multicast address when the consumer(subscriber) is offline for more than 5
min. I see in activemq classic there is a offlineDurableSubscriberTimeout
config that do just what i need. However it is not available in artemis. Is
there another way to achieve this?
I have tried setting connection-ttl-override=300000,
auto-delete-queues=true, auto-delete-queues-message-count=-1 on the broker
hopping that it would see the consumer/subscriber disconnected for more
than 5 min and cleanup the connection thus effectively delete the
subscription queue but it did not
-- 
Where there is will, there is a way

Re: offlineDurableSubscriberTimeout in artemis

Posted by Justin Bertram <jb...@apache.org>.
You need <auto-delete-created-queues>true</auto-delete-created-queues>
because subscription queues for durable JMS subscribers are not technically
considered auto-created. Keep in mind that addresses and queues are
independent. Just because an address is auto-created doesn't necessarily
mean that a queue is.

Generally speaking, it's totally fine to use '.' in the name of a queue or
address. In fact, '.' is the default delimiter [1] so the broker expects it
to be used in address names at the very least. I'm not sure why it would be
escaped like that. Can you provide more information? Your description is
pretty light on details.


Justin

[1]
https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html

On Tue, Apr 18, 2023 at 1:48 PM Thai Le <ln...@gmail.com> wrote:

> Thanks Justin, It works, but i am not sure why i need
> <auto-delete-created-queues>true</auto-delete-created-queues>, my queues
> are auto created, and i can see from web console that their address has
> AutoCreated=true.
>
> Regarding the specific addressSettings for queues, i am trying to do that
> but some of my jms destination uses "." separation like
> QUEUE.service1.processing which cause the address be created with the .
> (QUEUE.service1.processing) but the queues created with \\.
> (QUEUE\\.service1\\.processing). Other than ".", are there other special
> chars that should not be used in queue name?
>
> Regards
>
> Thai Le
>
> On Tue, 18 Apr 2023 at 13:39, Justin Bertram <jb...@apache.org> wrote:
>
> > I think this should work:
> >
> >     <auto-delete-queues>true</auto-delete-queues>
> >     <auto-delete-created-queues>true</auto-delete-created-queues>
> >     <auto-delete-queues-delay>300000</auto-delete-queues-delay> <!-- 5
> > minutes -->
> >
>  <auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
> >     <auto-delete-addresses>true</auto-delete-addresses>
> >
> > However, I *strongly* recommend you use a very specific address-setting
> > match value with these settings. Your current settings are using "#"
> which
> > will apply to *all* addresses and those settings will delete *any*
> > auto-created queue without a consumer no matter how many messages it has.
> > This could lead to inadvertent message loss.
> >
> >
> > Justin
> >
> > On Tue, Apr 18, 2023 at 12:13 PM Thai Le <ln...@gmail.com> wrote:
> >
> > > Thank you for quick response.
> > > -Some of our application are python using STOMP protocol to listen to
> > > queue, the others are spring boot app and listening to queue using
> > > JmsListener and their application.propeties has
> > spring.artemis.mode=native
> > > so I assume they are using CORE.
> > > -I am currently testing on 2.19 but I also need to upgrade to 2.28
> > > -here are my addressSettings:
> > >
> > >  <addressSettings>
> > >
> > > <address-setting match="activemq.management#">
> > > <dead-letter-address>DLQ</dead-letter-address>
> > > <expiry-address>ExpiryQueue</expiry-address>
> > > <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>
> > > </address-setting>
> > >
> > > <!--default for catch all-->
> > > <address-setting match="#">
> > > <dead-letter-address>DLQ</dead-letter-address>
> > > <expiry-address>ExpiryQueue</expiry-address>
> > > <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>true</auto-delete-queues>
> > >
> > > <auto-delete-addresses>true</auto-delete-addresses>
> > >
> > > <auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
> > >
> > > </address-setting>
> > >
> > > </address-settings>
> > >
> > > -the reason for connection-ttl-override is here because i am testing if
> > it
> > > has any impact on the auto delete durable subscriber but i dont see any
> > > different .
> > >
> > >
> > > Regards
> > >
> > > Thai Le
> > >
> > > On Tue, 18 Apr 2023 at 12:32, Justin Bertram <jb...@apache.org>
> > wrote:
> > >
> > > > You should be able to remove the subscription queue with the right
> > > > combination of address-settings. I've got a few questions to clarify
> > the
> > > > use-case a bit:
> > > >
> > > >  - What protocol is the durable subscriber using?
> > > >  - What version of ActiveMQ Artemis are you using?
> > > >  - What are all of your existing address-settings for the address in
> > > > question?
> > > >  - What purpose would setting the connection-ttl-override serve here?
> > Is
> > > > the subscriber connected but idle? Is the subscriber's connection
> > broken
> > > > but the broker doesn't realize it?
> > > >
> > > >
> > > > Justin
> > > >
> > > > On Tue, Apr 18, 2023 at 11:20 AM Thai Le <ln...@gmail.com>
> wrote:
> > > >
> > > > > Hello,
> > > > > I would like to auto unsubscribe a durable subscription from a
> > > > > multicast address when the consumer(subscriber) is offline for more
> > > than
> > > > 5
> > > > > min. I see in activemq classic there is a
> > > offlineDurableSubscriberTimeout
> > > > > config that do just what i need. However it is not available in
> > > artemis.
> > > > Is
> > > > > there another way to achieve this?
> > > > > I have tried setting connection-ttl-override=300000,
> > > > > auto-delete-queues=true, auto-delete-queues-message-count=-1 on the
> > > > broker
> > > > > hopping that it would see the consumer/subscriber disconnected for
> > more
> > > > > than 5 min and cleanup the connection thus effectively delete the
> > > > > subscription queue but it did not
> > > > > --
> > > > > Where there is will, there is a way
> > > > >
> > > >
> > >
> > >
> > > --
> > > Where there is will, there is a way
> > >
> >
>
>
> --
> Where there is will, there is a way
>

Re: offlineDurableSubscriberTimeout in artemis

Posted by Thai Le <ln...@gmail.com>.
Thanks Justin, It works, but i am not sure why i need
<auto-delete-created-queues>true</auto-delete-created-queues>, my queues
are auto created, and i can see from web console that their address has
AutoCreated=true.

Regarding the specific addressSettings for queues, i am trying to do that
but some of my jms destination uses "." separation like
QUEUE.service1.processing which cause the address be created with the .
(QUEUE.service1.processing) but the queues created with \\.
(QUEUE\\.service1\\.processing). Other than ".", are there other special
chars that should not be used in queue name?

Regards

Thai Le

On Tue, 18 Apr 2023 at 13:39, Justin Bertram <jb...@apache.org> wrote:

> I think this should work:
>
>     <auto-delete-queues>true</auto-delete-queues>
>     <auto-delete-created-queues>true</auto-delete-created-queues>
>     <auto-delete-queues-delay>300000</auto-delete-queues-delay> <!-- 5
> minutes -->
>     <auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
>     <auto-delete-addresses>true</auto-delete-addresses>
>
> However, I *strongly* recommend you use a very specific address-setting
> match value with these settings. Your current settings are using "#" which
> will apply to *all* addresses and those settings will delete *any*
> auto-created queue without a consumer no matter how many messages it has.
> This could lead to inadvertent message loss.
>
>
> Justin
>
> On Tue, Apr 18, 2023 at 12:13 PM Thai Le <ln...@gmail.com> wrote:
>
> > Thank you for quick response.
> > -Some of our application are python using STOMP protocol to listen to
> > queue, the others are spring boot app and listening to queue using
> > JmsListener and their application.propeties has
> spring.artemis.mode=native
> > so I assume they are using CORE.
> > -I am currently testing on 2.19 but I also need to upgrade to 2.28
> > -here are my addressSettings:
> >
> >  <addressSettings>
> >
> > <address-setting match="activemq.management#">
> > <dead-letter-address>DLQ</dead-letter-address>
> > <expiry-address>ExpiryQueue</expiry-address>
> > <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>
> > </address-setting>
> >
> > <!--default for catch all-->
> > <address-setting match="#">
> > <dead-letter-address>DLQ</dead-letter-address>
> > <expiry-address>ExpiryQueue</expiry-address>
> > <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>true</auto-delete-queues>
> >
> > <auto-delete-addresses>true</auto-delete-addresses>
> >
> > <auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
> >
> > </address-setting>
> >
> > </address-settings>
> >
> > -the reason for connection-ttl-override is here because i am testing if
> it
> > has any impact on the auto delete durable subscriber but i dont see any
> > different .
> >
> >
> > Regards
> >
> > Thai Le
> >
> > On Tue, 18 Apr 2023 at 12:32, Justin Bertram <jb...@apache.org>
> wrote:
> >
> > > You should be able to remove the subscription queue with the right
> > > combination of address-settings. I've got a few questions to clarify
> the
> > > use-case a bit:
> > >
> > >  - What protocol is the durable subscriber using?
> > >  - What version of ActiveMQ Artemis are you using?
> > >  - What are all of your existing address-settings for the address in
> > > question?
> > >  - What purpose would setting the connection-ttl-override serve here?
> Is
> > > the subscriber connected but idle? Is the subscriber's connection
> broken
> > > but the broker doesn't realize it?
> > >
> > >
> > > Justin
> > >
> > > On Tue, Apr 18, 2023 at 11:20 AM Thai Le <ln...@gmail.com> wrote:
> > >
> > > > Hello,
> > > > I would like to auto unsubscribe a durable subscription from a
> > > > multicast address when the consumer(subscriber) is offline for more
> > than
> > > 5
> > > > min. I see in activemq classic there is a
> > offlineDurableSubscriberTimeout
> > > > config that do just what i need. However it is not available in
> > artemis.
> > > Is
> > > > there another way to achieve this?
> > > > I have tried setting connection-ttl-override=300000,
> > > > auto-delete-queues=true, auto-delete-queues-message-count=-1 on the
> > > broker
> > > > hopping that it would see the consumer/subscriber disconnected for
> more
> > > > than 5 min and cleanup the connection thus effectively delete the
> > > > subscription queue but it did not
> > > > --
> > > > Where there is will, there is a way
> > > >
> > >
> >
> >
> > --
> > Where there is will, there is a way
> >
>


-- 
Where there is will, there is a way

Re: offlineDurableSubscriberTimeout in artemis

Posted by Justin Bertram <jb...@apache.org>.
I think this should work:

    <auto-delete-queues>true</auto-delete-queues>
    <auto-delete-created-queues>true</auto-delete-created-queues>
    <auto-delete-queues-delay>300000</auto-delete-queues-delay> <!-- 5
minutes -->
    <auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
    <auto-delete-addresses>true</auto-delete-addresses>

However, I *strongly* recommend you use a very specific address-setting
match value with these settings. Your current settings are using "#" which
will apply to *all* addresses and those settings will delete *any*
auto-created queue without a consumer no matter how many messages it has.
This could lead to inadvertent message loss.


Justin

On Tue, Apr 18, 2023 at 12:13 PM Thai Le <ln...@gmail.com> wrote:

> Thank you for quick response.
> -Some of our application are python using STOMP protocol to listen to
> queue, the others are spring boot app and listening to queue using
> JmsListener and their application.propeties has spring.artemis.mode=native
> so I assume they are using CORE.
> -I am currently testing on 2.19 but I also need to upgrade to 2.28
> -here are my addressSettings:
>
>  <addressSettings>
>
> <address-setting match="activemq.management#">
> <dead-letter-address>DLQ</dead-letter-address>
> <expiry-address>ExpiryQueue</expiry-address>
> <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>
> </address-setting>
>
> <!--default for catch all-->
> <address-setting match="#">
> <dead-letter-address>DLQ</dead-letter-address>
> <expiry-address>ExpiryQueue</expiry-address>
> <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>true</auto-delete-queues>
>
> <auto-delete-addresses>true</auto-delete-addresses>
>
> <auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
>
> </address-setting>
>
> </address-settings>
>
> -the reason for connection-ttl-override is here because i am testing if it
> has any impact on the auto delete durable subscriber but i dont see any
> different .
>
>
> Regards
>
> Thai Le
>
> On Tue, 18 Apr 2023 at 12:32, Justin Bertram <jb...@apache.org> wrote:
>
> > You should be able to remove the subscription queue with the right
> > combination of address-settings. I've got a few questions to clarify the
> > use-case a bit:
> >
> >  - What protocol is the durable subscriber using?
> >  - What version of ActiveMQ Artemis are you using?
> >  - What are all of your existing address-settings for the address in
> > question?
> >  - What purpose would setting the connection-ttl-override serve here? Is
> > the subscriber connected but idle? Is the subscriber's connection broken
> > but the broker doesn't realize it?
> >
> >
> > Justin
> >
> > On Tue, Apr 18, 2023 at 11:20 AM Thai Le <ln...@gmail.com> wrote:
> >
> > > Hello,
> > > I would like to auto unsubscribe a durable subscription from a
> > > multicast address when the consumer(subscriber) is offline for more
> than
> > 5
> > > min. I see in activemq classic there is a
> offlineDurableSubscriberTimeout
> > > config that do just what i need. However it is not available in
> artemis.
> > Is
> > > there another way to achieve this?
> > > I have tried setting connection-ttl-override=300000,
> > > auto-delete-queues=true, auto-delete-queues-message-count=-1 on the
> > broker
> > > hopping that it would see the consumer/subscriber disconnected for more
> > > than 5 min and cleanup the connection thus effectively delete the
> > > subscription queue but it did not
> > > --
> > > Where there is will, there is a way
> > >
> >
>
>
> --
> Where there is will, there is a way
>

Re: offlineDurableSubscriberTimeout in artemis

Posted by Thai Le <ln...@gmail.com>.
Thank you for quick response.
-Some of our application are python using STOMP protocol to listen to
queue, the others are spring boot app and listening to queue using
JmsListener and their application.propeties has spring.artemis.mode=native
so I assume they are using CORE.
-I am currently testing on 2.19 but I also need to upgrade to 2.28
-here are my addressSettings:

 <addressSettings>

<address-setting match="activemq.management#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<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>
</address-setting>

<!--default for catch all-->
<address-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<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>true</auto-delete-queues>

<auto-delete-addresses>true</auto-delete-addresses>

<auto-delete-queues-message-count>-1</auto-delete-queues-message-count>

</address-setting>

</address-settings>

-the reason for connection-ttl-override is here because i am testing if it
has any impact on the auto delete durable subscriber but i dont see any
different .


Regards

Thai Le

On Tue, 18 Apr 2023 at 12:32, Justin Bertram <jb...@apache.org> wrote:

> You should be able to remove the subscription queue with the right
> combination of address-settings. I've got a few questions to clarify the
> use-case a bit:
>
>  - What protocol is the durable subscriber using?
>  - What version of ActiveMQ Artemis are you using?
>  - What are all of your existing address-settings for the address in
> question?
>  - What purpose would setting the connection-ttl-override serve here? Is
> the subscriber connected but idle? Is the subscriber's connection broken
> but the broker doesn't realize it?
>
>
> Justin
>
> On Tue, Apr 18, 2023 at 11:20 AM Thai Le <ln...@gmail.com> wrote:
>
> > Hello,
> > I would like to auto unsubscribe a durable subscription from a
> > multicast address when the consumer(subscriber) is offline for more than
> 5
> > min. I see in activemq classic there is a offlineDurableSubscriberTimeout
> > config that do just what i need. However it is not available in artemis.
> Is
> > there another way to achieve this?
> > I have tried setting connection-ttl-override=300000,
> > auto-delete-queues=true, auto-delete-queues-message-count=-1 on the
> broker
> > hopping that it would see the consumer/subscriber disconnected for more
> > than 5 min and cleanup the connection thus effectively delete the
> > subscription queue but it did not
> > --
> > Where there is will, there is a way
> >
>


-- 
Where there is will, there is a way

Re: offlineDurableSubscriberTimeout in artemis

Posted by Justin Bertram <jb...@apache.org>.
You should be able to remove the subscription queue with the right
combination of address-settings. I've got a few questions to clarify the
use-case a bit:

 - What protocol is the durable subscriber using?
 - What version of ActiveMQ Artemis are you using?
 - What are all of your existing address-settings for the address in
question?
 - What purpose would setting the connection-ttl-override serve here? Is
the subscriber connected but idle? Is the subscriber's connection broken
but the broker doesn't realize it?


Justin

On Tue, Apr 18, 2023 at 11:20 AM Thai Le <ln...@gmail.com> wrote:

> Hello,
> I would like to auto unsubscribe a durable subscription from a
> multicast address when the consumer(subscriber) is offline for more than 5
> min. I see in activemq classic there is a offlineDurableSubscriberTimeout
> config that do just what i need. However it is not available in artemis. Is
> there another way to achieve this?
> I have tried setting connection-ttl-override=300000,
> auto-delete-queues=true, auto-delete-queues-message-count=-1 on the broker
> hopping that it would see the consumer/subscriber disconnected for more
> than 5 min and cleanup the connection thus effectively delete the
> subscription queue but it did not
> --
> Where there is will, there is a way
>