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.
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.