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 <lnthai2...@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 <jbert...@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 <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 > > > > > > > > -- > Where there is will, there is a way >
