Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.5.1
-
None
-
- Machine:
It's an EC2 instance on AWS cloud of type m4.large: 2 vCPU, 8G RAM and SSD storage.
- OS:
CentOS Linux release 7.3.1611 (Core) - x86_64
- JVM:
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
- Distro package version of libaio:
Arch : x86_64
Version : 0.3.109
Release : 13.el7
Machine: It's an EC2 instance on AWS cloud of type m4.large: 2 vCPU, 8G RAM and SSD storage. OS: CentOS Linux release 7.3.1611 (Core) - x86_64 JVM: java version "1.8.0_111" Java(TM) SE Runtime Environment (build 1.8.0_111-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode) Distro package version of libaio: Arch : x86_64 Version : 0.3.109 Release : 13.el7 - Machine:
Description
I'm testing the "retained message" feature of MQTT protocol.
It seems that the broker works well while the retained messages are kept in ram: messages are sent correctly.
But when the Broker needs to recover and send the retained messages from the file system (e.g. after a restart), clients receive them with weird chars inside.
Following are the steps to reproduce the behaviour:
[Server Side]
1. Create a dedicated user and a folder for the Broker installation (with right permission for that user)
2. Set JAVA_HOME environment variable for the above user (jdk 1.8.0_111 in my case), download and unpack apache artemis 1.5.1.
3. Create a broker instance (set a username, password and role).
4. cd into the just created broker folder and create a user by using the following command:
bin/artemis user add
--> set username = <username>
--> set password = <password>
--> set role = mqtt
5. Set the broker.xml file accordingly to the attached one (by changing ip and folder references).
6. Run the broker: in foreground ("bin/artemis run") or as a service (bin/artemis-service start) it's the same.
[Client Side]
7. use a mqtt client to publish a retained message on a topic. E.g. with mosquitto client the command could be the following:
mosquitto_pub -d -h <broker_ip> -p 1883 -u <user> -P <password> -t /topic/test -r -q <QoS> -m "test for a retained message"
8. use a mqtt client to subscribe the same topic specified in the previous step. E.g.:
mosquitto_sub -d -h <broker_ip> -p 1883 -u <user> -P <password> -q <QoS> -t /topic/test
...it receives the retained message sent in previous step. The message is good.
[Server Side]
9. Stop the Broker: "bin/artemis stop" or "bin/artemis-service stop"
10. Wait until the Broker finishes to stop ("stopped" in the log) and then restart it: "bin/artemis run" or "bin/artemis-service start". Check until it's up and running.
[Client Side]
11. use a mqtt client to subscribe the same topic specified in step 7/8. E.g.:
mosquitto_sub -d -h <broker_ip> -p 1883 -u <user> -P <password> -q <QoS> -t /topic/test
...HERE THE ISSUE: it receives the same retained message published in step 7, but with weird chars inside.
12. If you try to replicate steps 7 and 8 (publish a new retained message and subscribe to receive it) you will notice that the new retained message comes back to be clean (no weird chars).
NOTE: it doesn't matter the client used for test. I replicated the same behaviour by using mosquitto_client, mqtt-spy and mqtt.fx
Attachments
Attachments
Issue Links
- is duplicated by
-
ARTEMIS-916 Retained messages from file system contain weird chars
- Closed
- links to