[ARTEMIS-3307] Addresses not cleaned up correctly in case of Wildcard Subscriptions

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.16.0, 2.17.0
• Component/s: MQTT

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

 

• Assignee: Unassigned
• Reporter: Andreas Hubert
• Created: 19/May/21 16:11
• Updated: 19/May/21 16:15

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:

<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> 

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).