Client buffer stops storing offline messages
SirHeisenberg opened this issue · comments
I have a problem with the client's "buffer".
When it loses connection with the broker and you try to publish messages offline it does store them and publishes them when the connection is back.
It works for the first 2 or 3 times that it loses connection but after that it just stops storing messages.
Which QOS level are you using for the connection? Sent from ProtonMail mobile
…
-------- Original Message --------
On Sep 10, 2019, 12:16, SirHeisenberg wrote: I have a problem with the client's "buffer". When it loses connection with the broker and you try to publish messages offline it does store them and publishes them when the connection is back. It works for the first 2 or 3 times that it loses connection but after that it just stops storing messages. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
I'm trying with QoS 1 and 2, I have the same issue using both of them.
Well that's weird. I thought it had it implemented since when you lose connection with the broker, before it disconnects (within the keepAliveInterval), sometimes it stores the messages that you tried to send and publish them back when the connection is restored.
This happens sometimes before being disconnected due to the keepAliveInterval.
So if I disconnect my client from the network (disable ethernet connection or wifi), then I publish a few messages and then connect to the network again (before being recognized as disconnected from the broker side due to keepAliveInterval), it will publish those messages I sent while I didn't have connection (ethernet disable).
I have double checked the code. What happens is this: when you call the publish function in the Client class, the data is written directly to the underlying socket, if is has the 'connected' state. If it is not connected the data will be dropped. We do not keep a list of messages that should be sent later in case the initial write fails. In your case, this could happen (warning: I'm not an expert on this matter): maybe the OS detects the hardware disconnect and tries to reconnect. For a while it may data that has been sent over any socket in case a quick reconnect is possible. In theory the application would not even notice the problem if the reconnect succeeds. Anyway, that's the only explanation I can think of. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
…
On Wednesday, September 11, 2019 7:45 AM, SirHeisenberg @.***> wrote: Well that's weird. I thought it had it implemented since when you lose connection with the broker, before it disconnects (within the keepAliveInterval), sometimes it stores the messages that you tried to send and publish them back when the connection is restored. This happens sometimes before being disconnected due to the keepAliveInterval. So if I disconnect my client from the network (disable ethernet connection or wifi), then I publish a few messages and then connect to the network again (before being recognized as disconnected from the broker side due to keepAliveInterval), it will publish those messages I sent while I didn't have connection (ethernet disable). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Alright thanks!!
I have another problem but I'll make a new issue since is a different problem.