ActiveMQ Artemis does not respect broker.xml settings for queue deletion and queue configuration

I'm running ActiveMQ Artemis 2.28.0 with a broker config as shown below. I left the things in which I think are relevant (mainly default settings).

I am sure the file is actually used because if I disable auto-create-queues for example I do get errors as expected, but other settings just seem to be ignored in my use case.

<configuration xmlns="urn:activemq"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xi="http://www.w3.org/2001/XInclude"
               xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">
   <core xmlns="urn:activemq:core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:activemq:core ">

      <address-settings>
         <!-- if you define auto-create on certain queues, management has to be auto-create -->
         <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>
         </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>
            <max-size-bytes>-1</max-size-bytes>
            <max-size-messages>-1</max-size-messages>
            <page-size-bytes>10M</page-size-bytes>
            <max-read-page-messages>-1</max-read-page-messages>
            <max-read-page-bytes>20M</max-read-page-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-delete-queues>false</auto-delete-queues>
            <auto-delete-addresses>false</auto-delete-addresses>

            <auto-delete-created-queues>false</auto-delete-created-queues>
            <default-exclusive-queue>false</default-exclusive-queue>
            <default-max-consumers>-1</default-max-consumers>

         </address-setting>
      </address-settings>

      <address-queue-scan-period>-1</address-queue-scan-period>

      <addresses>
         <address name="DLQ">
            <anycast>
               <queue name="DLQ" />
            </anycast>
         </address>
         <address name="ExpiryQueue">
            <anycast>
               <queue name="ExpiryQueue" />
            </anycast>
         </address>
      </addresses>
   </core>
</configuration>

With these settings I have following expectations:

queues are auto-created when needed
when a consumer stops listening to a queue both the queue and the address still exists
more than one consumer can join the queue if necessary

However, the behaviour I observe is as follows:

when creating a (multicast) consumer the queue is automatically created
the created queue has a maxConsumerCount of 1 even though the default is set to -1
when I close my session both the queue and the address are deleted, even though the queue has auto-delete-queues set to false

As a possible workaround I also added the address-queue-scan-period value but this doesn't make a difference in the observed behaviour.

This is a trace of creation which shows the incorrect maxConsumers value

2023-06-15 15:56:05,251 DEBUG [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843006: beforeCreateQueue called with queueConfig: QueueConfiguration [id=null, name=C7GN9YMV1P53I5PI.receiver, address=linda.acc.train.behaviour.12, routingType=MULTICAST, filterString=SubscriptionId='C7GN9YMV1P53I5PI' OR SubscriptionId IS NULL, durable=null, user=admin, maxConsumers=1, exclusive=false, groupRebalance=false, groupRebalancePauseDispatch=false, groupBuckets=-1, groupFirstKey=null, lastValue=false, lastValueKey=null, nonDestructive=false, purgeOnNoConsumers=false, enabled=true, consumersBeforeDispatch=0, delayBeforeDispatch=-1, consumerPriority=null, autoDelete=false, autoDeleteDelay=0, autoDeleteMessageCount=0, ringSize=-1, configurationManaged=null, temporary=null, autoCreateAddress=true, internal=null, transient=null, autoCreated=null]

When the consumer is closed below log indicates the queue and the address is destroyed which does not match with my settings.

2023-06-15 15:56:35,559 INFO  [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841006: closed consumer ID: 0, with  consumer Session: 5ef8b4b4-0b84-11ee-be26-d6283bc2e653, failed: false
2023-06-15 15:56:35,568 DEBUG [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843007: beforeDestroyQueue called with queueName: C7GN9YMV1P53I5PI.receiver, session: ServerSessionImpl(), checkConsumerCount: true, removeConsumers: false, autoDeleteAddress: true

At this point I don't really know if I'm running against a bug or if I'm misunderstanding the setup parameters.

Solution

I believe you have misunderstood the automatic address & queue creation functionality. Automatic address & queue creation only applies in situations where the address or queue wouldn't be created otherwise for normal operation. For example if a JMS producer sent a message to a JMS queue that didn't already exist in broker.xml then with the default settings the corresponding address & anycast queue would be created and the message would be stored in that queue.

That said, technically speaking queues are automatically created in multicast (i.e. pub/sub) use-cases regardless of the auto-create settings in broker.xml. The documentation typically refers to these queues as "subscription queues." For example, if a JMS consumer subscribed to a JMS topic whose corresponding address was already configured in broker.xml then a multicast queue for the consumer's subscription would be created automatically regardless of the auto-creation configuration. This is because the subscription queue is required for normal multicast semantics. If subscription queues weren't automatically created then you would have to manually configure the multicast queue in broker.xml for every subscriber which is unrealistic. Historically speaking, this behavior existed long before there was any other notion of address & queue auto-creation.

Furthermore, certain settings are applied to subscription queues regardless of the configuration of the default-* address-settings (e.g. default-max-consumers, default-exclusive). This is due to the nature of the particular subscription queue. For example, in JMS subscriptions can be shared or unshared & durable or non-durable. Unshared subscription queues have a max-consumer count of 1 because they are never supposed to be shared (i.e. have > 1 consumer).