Thanks for your reply.
About
> Setting "auto-delete-created-queues" to "true" is rarely a good idea. Is
there a specific reason you did that?
Unfortunately I have a lot of queues created by MQTT clients through
subscriptions that are lets say “volatile”. These clients can create a lot of
different subscriptions and stay connected for a very long time.
Without this setting do the autocreated queues stay forever? Or are anyway
destroyed even when the client is still connected or the client disconnect
without doing unsubscribes?
I though the autodelete option didn’t nothing to the queues coming from durable
subscriptions. Is there any other way to mark these queues as not erasable?
To make the scenario more complex these queues I wouldn’t to be erased are
dynamics in number and names so it’s hard to hardcode a regex in the broker.xml
configuration.
Do you have any suggestion to achieve it?
I tried but it looks like not working as I expected especially with topics
starting with $.
Is the match expression a topic expression with wildcards allowed? In other
word to specify all the topics starting with something and having depth of at
least 3 can I write this expression (having wildcards set according to MQTT
protocol): “something/+/+/#”
Riccardo
From: Justin Bertram <jbert...@apache.org>
Date: Tuesday, 10 October 2023 at 18:55
To: users@activemq.apache.org <users@activemq.apache.org>
Subject: Re: Artemis deletes (wrongly?) queues associated to shared durable
subscription
> The broker shouldn’t delete a queue associated to shared durable
subscriptions even if no consumers are active at that moment and should
store all the messages in the meanwhile. Am I right?
You are correct. However, it appears to me that you've actually configured
the broker to override the default semantics here and remove the queue
you're asking about. Your auto-delete settings are very aggressive, i.e.:
<address-setting match="#">
...
<auto-delete-queues>true</auto-delete-queues>
<auto-delete-created-queues>true</auto-delete-created-queues>
<auto-delete-queues-delay>1000</auto-delete-queues-delay>
<auto-delete-queues-message-count>0</auto-delete-queues-message-count>
<auto-delete-addresses>true</auto-delete-addresses>
<auto-delete-addresses-delay>1000</auto-delete-addresses-delay>
</address-setting>
This will basically delete *any* queue (whether or not it was auto-created)
that has 0 messages and sits idle (i.e. without a consumer) for 1 second. I
recommend you dial this back a bit so that only auto-created queues are
auto-deleted and perhaps extend the time-to-wait, e.g.:
<address-setting match="#">
...
<auto-delete-queues>true</auto-delete-queues>
<auto-delete-created-queues>false</auto-delete-created-queues>
<auto-delete-queues-delay>300000</auto-delete-queues-delay>
<auto-delete-queues-message-count>0</auto-delete-queues-message-count>
<auto-delete-addresses>true</auto-delete-addresses>
<auto-delete-addresses-delay>300000</auto-delete-addresses-delay>
</address-setting>
Setting "auto-delete-created-queues" to "true" is rarely a good idea. Is
there a specific reason you did that?
Justin
On Tue, Oct 10, 2023 at 10:58 AM Modanese, Riccardo
<riccardo.modan...@eurotech.com.invalid> wrote:
> Hello,
> my issue is not completely bound to Artemis (involves Camel also) so
> I’m trying to ask here first.
>
> From the JMS specs 2.0 and AMQP I found, the behavior of the shared
> durable subscriptions is still the same as for JMS 1.x specs.
> The broker shouldn’t delete a queue associated to shared durable
> subscriptions even if no consumers are active at that moment and should
> store all the messages in the meanwhile. Am I right?
>
> In my scenario I have a Camel AMQP consumer (Spring Boot + Camel 3.21 –
> qpid JMS connection factory) connected to Artemis broker (2.28.0) with
> shared durable subscriptions. The client id is uniquely set by a specific
> extension of the standard factory I did.
>
> The Camel subscription is (from my camel.xml):
>
>
> <from uri="amqp:topic://something/#?
>
> selector=key='value'&
>
> asyncConsumer=true&
>
> acknowledgementModeName=CLIENT_ACKNOWLEDGE&
>
> transacted=false&
>
> durableSubscriptionName=myConsumer&
>
> subscriptionShared=true&
>
> concurrentConsumers=2&
>
> maxConcurrentConsumers=5"/>
>
>
> This consumer is running on a different Docker container than the broker.
> If I kill the consumer’s container, then after a while the associated
> queue is automatically deleted.
>
> This is my address settings in broker.xml
>
> <address-setting match="#">
> <dead-letter-address>DLQ</dead-letter-address>
> <expiry-address>ExpiryQueue</expiry-address>
> <!-- <expiry-delay>10</expiry-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>true</auto-delete-queues>
> <auto-delete-created-queues>true</auto-delete-created-queues>
> <auto-delete-queues-delay>1000</auto-delete-queues-delay>
> <auto-delete-queues-message-count>0</auto-delete-queues-message-count>
> <auto-delete-addresses>true</auto-delete-addresses>
> <auto-delete-addresses-delay>1000</auto-delete-addresses-delay>
> </address-setting>
> …..
> <wildcard-addresses>
> <routing-enabled>true</routing-enabled>
> <delimiter>/</delimiter>
> <any-words>#</any-words>
> <single-word>+</single-word>
> </wildcard-addresses>
>
>
>
> Regards
>
> Riccardo Modanese
>
