Keep alive ping while connection is still active about rumqtt HOT 9 CLOSED

Yeah this used to be the case, but I changed it for simplicity (and forgot to update the docs)

https://github.com/bytebeamio/rumqtt/blob/master/rumqttc/src/eventloop.rs#L201-L202

Is this an issue in your case?

from rumqtt.

I only detected it because, for some reason (perhaps broker stress due to amount of requests), I received an error on eventloop because of it.

[2020-07-28T00:39:09Z ERROR rumqttc::state] Error awaiting for last ping response
[2020-07-28T00:39:09Z ERROR dt_client] MqttState(AwaitPingResp)

This caused disconnection, which lead to subscriber missing messages. I still need to refactor my subscriber to use rumqttc and not rumq-client, but the pinging behaviour happened on both. My publisher has already changed to rumqttc, and I used the matching behaviour I described above so the application doesn't crash on unwrapping the error message.

But thanks for the answer on the keep_alive. I'll just ping it less frequently.

For the issue itself, I believe just updating the documentation is more apropriate.
For the other point, i'm not sure how ping requests and responses work in MQTT to suggest an alternative. I'll see if refactoring on the subscriber to ignore this error is enough to not lose these messages.

from rumqtt.

That error is important. You shouldn't ignore that error. It detects half-open connections.

from rumqtt.

How would I handle these errors?
The examples only unwrap on the eventloop, so the application immediately crashes.

from rumqtt.

Sorry I mean the library shouldn't ignore these errors. Let me check if I understood your question correctly.

• Your broker (for some reason) is not sending ping responses
• You want the client to not get disconnected when this happens?

from rumqtt.

* Your broker (for some reason) is not sending ping responses

Yes, not consistently, just occasionally. I haven't been able to debug the reason behind it.

* You want the client to not get disconnected when this happens?

Yes, because until the subscriber program subscribes again, the broker discards a good amount of messages sent.
I believe this could be mitigated with retention and QoS changes, but it would depend on the broker implementation, not the client.
For the client itself, I believe that closing the connection on ping errors is not the ideal way of handling messages, if connection is still working, but failed for one ping.

from rumqtt.

Yes, because until the subscriber program subscribes again, the broker discards a good amount of messages sent.
I believe this could be mitigated with retention and QoS changes, but it would depend on the broker implementation, not the client.

Is there a reason you are not using persistent session? Most (reasonable) brokers will have offline peristence when clean session = false

For the client itself, I believe that closing the connection on ping errors is not the ideal way of handling messages, if connection is still working, but failed for one ping

Unfortunately, that's not possible. That one ping failing detects half-open connections as soon as possible and reconnects

from rumqtt.

Is there a reason you are not using persistent session? Most (reasonable) brokers will have offline peristence when clean session = false

It's just not using message retention by default. Haven't tested with the configuration enabled yet.
I'll update if it's enough to not lose messages due to this disconnection.

from rumqtt.

Closed because it indeed helped.
Other source of lost packets was reaching max queue size on the broker. Setting a larger queue made lost packet count reach zero, but of course this depends on each implementation scenario, since queue sizes are needed due to broker not having infinite memory.

from rumqtt.