Andreas Hubert created ARTEMIS-3223:
---------------------------------------
Summary: MQTT spec violation when subscribed to wildcard topic on
redistribution
Key: ARTEMIS-3223
URL: https://issues.apache.org/jira/browse/ARTEMIS-3223
Project: ActiveMQ Artemis
Issue Type: Bug
Components: MQTT
Affects Versions: 2.17.0, 2.16.0
Environment: *Clients*
* For testing
** mosquitto_sub 1.4.15 (receiving client)
** mosquitto_pub 1.4.15 (sending client)
* Also happens with these clients
** PAHO Java MQTT3 Client
** HiveMQ Java MQTT3 Client (throws "Malformed topic" exception)
*Broker*
We first noticed the problem with version 2.16.0, and it still exists in
2.17.0. We're running Artemis in docker using vromero/activemq-artemis Cluster
connection is configured as follows:
{code:java}
<cluster-connections>
<cluster-connection name="activemq">
<connector-ref>netty-connector</connector-ref>
<retry-interval>500</retry-interval>
<use-duplicate-detection>true</use-duplicate-detection>
<message-load-balancing>ON_DEMAND</message-load-balancing>
<max-hops>1</max-hops>
<static-connectors>
<connector-ref>netty-connector</connector-ref>
<connector-ref>artemis0-connector</connector-ref>
</static-connectors>
</cluster-connection>
</cluster-connections> {code}
Address settings are configured as follows:
{code:java}
<address-settings xmlns="urn:activemq:core">
<address-setting match="test.*">
<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>600000</auto-delete-queues-delay>
<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>
<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-setting match="activemq.management#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<redelivery-delay>0</redelivery-delay>
<redistribution-delay>100</redistribution-delay>
<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-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQueue</expiry-address>
<redelivery-delay>0</redelivery-delay>
<redistribution-delay>30000</redistribution-delay>
<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>
<default-purge-on-no-consumers>false</default-purge-on-no-consumers>
<auto-delete-addresses>true</auto-delete-addresses>
<auto-delete-addresses-delay>600000</auto-delete-addresses-delay>
<auto-delete-queues>true</auto-delete-queues>
<auto-delete-queues-delay>60000</auto-delete-queues-delay>
<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}
Reporter: Andreas Hubert
This is a similar problem to ARTEMIS-2888 - if MQTT messages are redistributed
after a client has reconnected and the subscription contains wildcards, the
topic of the message contains the wildcard address, not the specific address
the message was addressed to.
*Step to reproduce*
# Connect the receiving client to node 1 with a durable session (aka
clean-session false) and subscribe to a topic containing wildcards, e.g.
*test.+.test1*
# Send a test message using another client to any node to topic
*test.1234.test1*. It should be delivered correctly.
# Disconnect the receiving client.
# Send a test message to each individual node of the cluster (containing a
unique payload for making them identifyable).
# Reconnect the receiving client to node 2 (it should work with any of the
nodes, even the previously used node 1).
# The receiving client will receive all messages. But only the messages of the
node the client is currently connected to will contain the correct topic. All
other messages will contain *test.+.test1* as the topic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
