Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.16.0, 2.17.0
-
None
-
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:
<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>
Address settings are configured as follows:
<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>
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: <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> Address settings are configured as follows: <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> - For testing
Description
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.
Note: Addresses are written in JMS form (x.y.z) instead of MQTT form (x/y/z).
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.
Attachments
Issue Links
- is caused by
-
-
- Resolved
-
- relates to
-
-
- Closed
-
- links to
