[
https://issues.apache.org/jira/browse/ARTEMIS-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742529#comment-17742529
]
Justin Bertram commented on ARTEMIS-4361:
-----------------------------------------
I believe this was already resolved in 2.29.0 via ARTEMIS-4249.
> MQTT subscription that fails auth leaves behind address and queue
> -----------------------------------------------------------------
>
> Key: ARTEMIS-4361
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4361
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
> Affects Versions: 2.26.0
> Reporter: Rich T
> Priority: Major
>
> When an MQTT client tries to create a subscription that is rejected due to
> auth failure an address and queue are created and left behind.
> For example client ID `client1` subscribes to `#` then the `#` address is
> created with a `client1.#` queue; this queue will quickly fill up with
> messages (as it captures all messages).
> `MQTTSubscriptionManager::addSubscription()` creates the queue for the
> subscription but `createConsumerForSubscriptionQueue()` call throws an
> `ActiveMQSecurityException` when auth rejected; the created queue is not then
> cleaned up.
> I'm using a wildcard address settings via config to cleanup these created
> queues, like this, but not a viable solution for all use cases:
>
> {code:java}
> config.addAddressSetting(wildcardConfiguration.getAnyWordsString(),
> new AddressSettings()
> .setAutoDeleteCreatedQueues(true)
> .setAutoDeleteAddressesDelay(1)
> .setAutoDeleteQueuesMessageCount(-1L)
> );{code}
>
>
> But this does not seem like good default behaviour as these leaked queues can
> quickly fill up with messages
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
