[
https://issues.apache.org/jira/browse/ARTEMIS-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-3307.
-------------------------------------
Resolution: Duplicate
> Addresses not cleaned up correctly in case of Wildcard Subscriptions
> --------------------------------------------------------------------
>
> Key: ARTEMIS-3307
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3307
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
> Affects Versions: 2.16.0, 2.17.0
> Environment: Broker:
> * Artemis 2.16.0, single node (no cluster at the moment due to ARTEMIS-3223)
> Clients:
> * mosquitto_sub 1.4.15
> * PAHO Java MQTT3 Client
> * HiveMQ Java MQTT3 Client
>
> Reporter: Andreas Hubert
> Assignee: Justin Bertram
> Priority: Major
>
> We use auto-created addresses (via address-settings) with auto-delete-address
> and auto-delete-queue true (and the corresponding delays, ... set correctly).
> The problem occurs via MQTT when using durable subscriptions (MQTT clean
> session false).
> Without wildcard subscriptions, queues and addresses will be deleted
> according to the scan period and the corresponding delays.
> If there is a wildcard address that matches a concrete (aka non-wildcard)
> address, the concrete address will not be deleted even if there is no queue
> listening directly to that address. In the web-UI, the address will appear as
> a leaf node and the wildcard queue will be shown in the "Binding names" and
> "All queues" attributes.
> The test scenarios assume the following address-setting configuration:
> {code:java}
> <address-settings xmlns="urn:activemq:core">
> <!-- ... -->
> <address-setting match="test.*.xxx">
> <default-purge-on-no-consumers>false</default-purge-on-no-consumers>
> <auto-delete-addresses>true</auto-delete-addresses>
> <auto-delete-addresses-delay>60000</auto-delete-addresses-delay>
> <auto-delete-queues>true</auto-delete-queues>
> <auto-delete-queues-delay>60000</auto-delete-queues-delay>
>
> <auto-delete-queues-message-count>-1</auto-delete-queues-message-count>
> <auto-delete-created-queues>true</auto-delete-created-queues>
> <dead-letter-address>DLQ</dead-letter-address>
> <expiry-address>ExpiryQueue</expiry-address>
> <redelivery-delay>5000</redelivery-delay>
> <redistribution-delay>30000</redistribution-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>
> <!-- ... -->
> </address-settings> {code}
> Test scenario (no wildcard):
> * Connect to broker via MQTT with client-ID client1 and clean-session flag
> false (aka using durable subscriptions)
> * Subscribe to "test/1234/xxx"
> * Disconnect the client
> * Wait 3 minutes (to account for the delays and scan period)
> * The queue client1-test.1234.xxx and the address test.1234.xxx have been
> deleted (are no longer visible via JMX, web UI, metrics, ...)
>
> Test scenario (with wildcard):
> * Connect to broker via MQTT with client-ID client1 and clean-session flag
> false (aka using durable subscriptions)
> * client1: Subscribe to "test/1234/xxx"
> * Connect to broker via MQTT with client-ID client2 and clean-session flag
> false (aka using durable subscriptions)
> * client2: Subscribe to "test/+/xxx"
> * client1: Disconnect the client
> * Wait 3 minutes (to account for the delays and scan period)
> * The queue client1-test.1234.xxx (is no longer visible via JMX, web UI,
> metrics, ...)
> * The address test.1234.xxx still exists. In its "Binding names" and "All
> queues" attributes it contains the queue client2-test.*.xxx
>
> This behaviour can lead to a strong increase in unused addresses, which makes
> the UI unresponsive and also increases memory usage of the broker (in
> addition to potential decrease in performance in situations where all
> addresses need to be scanned).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
