Open SLelong opened 2 years ago
Taking over this issue opened by a fellow colleague.
My next step should be to set up an environment reproducing the issue and make it possible for sharing. Yet he's reproduced it in a simplified environment, this should not be too long. In the meantime can anyone tell if there's obviously something in what we describe that shouldn't be done this way ?
I'd use the db_dump tool to actually look at the db, and see if there's any extra clients you may have forgotten about?
It's on the target side we experience the issue, and my colleague set up a fairly unitary test on this. I'll remake his bench to get the maximum information out of it still.
I also have the same problem reported by @SLelong I haven't no one another connection and I'm using with raspberry device. I use 2.0.20 version in docker container. In the chunk message there is this data read with db dump: " DB_CHUNK_MSG_STORE: Length: 441 Store ID: 1800711 Source Port: 1883 Source MID: 1833 Topic: edges/1-9-11 QoS: 1 Retain: 1 Payload Length: 391 Expiry Time: 0
DB_CHUNK_CLIENT_MSG: Length: 38 Client ID: local.f4bd245e31be.sgm Store ID: 1800711 MID: 4708 QoS: 1 Retain: 1 Direction: 1 State: 11 Dup: 0 "
The state of message is set to mosq_ms_queued. How can I change it to force resend?
This messages doesn't never received from server.
Platform: Ubuntu Mosquitto version : 2.0.15, but the issue is also observed in previous versions.
Initial condition
Action connection between the local mosquitto broker and the bridge is lost.
Observed result: When connection is lost, the database is growing and growing. When connection comes back, The size doesn't decrease as messages are transmitted to the other bridge. Most of the messages remain in the database even if they have been transmitted. Sporadically, the database can decrease, but the general direction is to increase. This behaviour is even more visible when the mosquitto service is restarted with "systemctl restart mosquitto.service". In this case, the database is growing at each restart.
Expected result: The database should be emptied when messages are transmitted to the bridge.