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

Address theoretical possibility of a TPS-throttled publish getting lost #320

Merged
merged 2 commits into from
Aug 21, 2023

Conversation

bretambrose
Copy link
Contributor

If extended flow control was on, there was a very small chance (based on timing) that a throttled publish could be dropped entirely by the client. At first it seemed like it should be happening all the time, but a close reading of the implementation shows why it didn't: the queue processing loop would check the next schedule time at the bottom and skip out when it was about to get throttled. Similarly, the next service time would honor throttling calculations, so the only way to lose the operation was to be slightly off by a matter of nanoseconds.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@bretambrose bretambrose changed the title Address theoretical possibility of a TPS-throttled getting lost Address theoretical possibility of a TPS-throttled publish getting lost Aug 21, 2023
@bretambrose bretambrose merged commit 9e2b12d into main Aug 21, 2023
31 checks passed
@bretambrose bretambrose deleted the Mqtt5FlowControlError branch August 21, 2023 18:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants