Andreas Hubert created ARTEMIS-3307:
---------------------------------------
Summary: 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.17.0, 2.16.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
We use auto-created addresses (via address-settings) with auto-delete-address
and auto-delete-queue true (and the corresponding delays, ... set correctly).
Without wildcard subscriptions, queues and adresses 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.3.4#803005)
