Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client retry delay/backoff not happening #737

chelliwell opened this issue Mar 22, 2018 · 1 comment


Copy link

commented Mar 22, 2018

[Not sure whether to add more detail about use of thread/loop etc – or indeed how to describe what the use is]

We’re using the 1.4.14 mosquittopp library for our client app (on Linux), and looking for some insight into how the reconnect_delay stuff works.
Our app sets this with reconnect_delay_set(10, 1200, true)
The connection is to Amazon Web Services (using TLS), and we do in some cases see the exponential backoff kick in. For example: start the app, get connected, then the connection is lost to the Internet (e.g. broadband router switched off). Our ‘on_disconnect’ callback sees an error code 1.

However another failure scenario is when the client does not have permissions enabled at AWS. In this case there is still no CONNACK shown as being received, but the ‘on_disconnect’ error code is 7. And no retry delay/backoff occurs – it just continually [several times per second] tries to reconnect.
Adding some debug into mosquitto_loop_forever(), we can see that this function doesn’t exit; it drops out of the inner ‘do { .. } while(run && rc != MOSQ_ERR_SUCCESS)’ loop, but then spins back to the ‘do { .. } while(run && rc == MOSQ_ERR_SUCCESS)’ loop.
This in turn is getting a zero return from mosquitto_loop(), and therefore ‘reconnects’ is being zeroed. Hence no backoff.

We thought that this sort of disconnect would fall within the realms of “the behaviour of the client when it has unexpectedly disconnected”. Are we mistaken in our interpretation, or is this a bug..?


ralight added a commit that referenced this issue Sep 4, 2019
Closes #737. Thanks to chelliwell.

This comment has been minimized.

Copy link

commented Sep 4, 2019

The back off behaviour is now fixed in the fixes branch for 1.6.5.

@ralight ralight closed this Sep 4, 2019
@ralight ralight added this to the 1.6.5 milestone Sep 4, 2019
ralight added a commit that referenced this issue Sep 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.