[
https://issues.apache.org/jira/browse/ARTEMIS-3223?focusedWorklogId=631518&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-631518
]
ASF GitHub Bot logged work on ARTEMIS-3223:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 30/Jul/21 09:30
Start Date: 30/Jul/21 09:30
Worklog Time Spent: 10m
Work Description: Elyytscha commented on pull request #3673:
URL: https://github.com/apache/activemq-artemis/pull/3673#issuecomment-889766653
Hello,
we tested already, but i'm not sure if we did everything correct.
redistribution on the same node is now okay with mqtt and clean session
false,
when you subscribe to a wildcard topic with clean session false, then
disconnect, then send 2 messages on node a and node b to a topic in this
wildcard range with different publisher, then reconnect the client, the
messages are appearing with their original topic, not with a wildcard anymore.
but we have some weird behavior with the management console and with same
steps above but connecting to node b instead of node a where subscriber was
connected before, it does not work, there are generally no messages arriving.
the weird error we see and why we cant check the settings in the webconsole is
actually:
```
artemis1_1 | 2021-07-29 20:07:33,496 WARN [io.hawt.system.Authenticator]
Login failed due to: No LoginModules configured for
activemq-management-management-management-management-management-management-management-management
artemis1_1 | 2021-07-29 20:07:34,026 WARN [io.hawt.system.Authenticator]
Login failed due to: No LoginModules configured for
activemq-management-management-management-management-management-management-management-management
artemis1_1 | 2021-07-29 20:07:35,454 WARN [io.hawt.system.Authenticator]
Login failed due to: No LoginModules configured for
activemq-management-management-management-management-management-management-management-management
```
with this login.config:
```
activemq {
org.apache.activemq.artemis.spi.core.security.jaas.GuestLoginModule
sufficient
debug=true
org.apache.activemq.jaas.guest.user="guest"
org.apache.activemq.jaas.guest.role="guest";
};
activemq-management {
org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule
sufficient
debug=true
org.apache.activemq.jaas.properties.user="artemis-users.properties"
org.apache.activemq.jaas.properties.role="artemis-roles.properties";
};
```
but i can't imagine how that should be related to this pullrequest, so i
think we have some errors in the setup or something has changed since activemq
2.16 which we used before.. so i think we have some configuration error, we are
investigating this..
best regards
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 631518)
Time Spent: 4.5h (was: 4h 20m)
> 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.16.0, 2.17.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
> Assignee: Gary Tully
> Priority: Major
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
