[
https://issues.apache.org/jira/browse/ARTEMIS-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Hubert updated ARTEMIS-3307:
------------------------------------
Description:
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).
was:
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).
> 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
> 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.3.4#803005)
