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 <lnthai2...@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 <jbert...@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 <lnthai2...@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
>
