Closed jpwsutton closed 5 years ago
Fixing the test to have an max inflight window of 100 is a temporary fix to this issue. As this issue hasn't been picked up by anyone in their own applications as far as I can see, I'm going to put this on the backlog for the next release. Once this has been fixed though, the testManyMessageBufferAndDeliver
test needs to have the max inflight setting removed.
I've added a possible fix in the v5 client as well, this will prevent publishes being sent until there are 4 spaces in the inflight window. This seemed to work for me, we could dynamically size this based on the qos of the message being sent?
That change doesn't fix the issue in the V5 client, I assume that setting maxInflight in the test will avoid the issue, but not fix it.
I've added a fix for this in the V5 client - a similar approach should work for V3 too. Basically it retries the publish when this condition occurs.
Released in 1.2.1
Please fill out the form below before submitting, thank you!
If this is a bug regarding the Android Service, please raise the bug here instead: https://github.com/eclipse/paho.mqtt.android/issues/new
After narrowing down in tests, I've identified the issue causing the OfflineBufferingTest class to intermittently fail in Travis and Jenkins.
It looks like the Disconnected Message Buffer accidentally its the In flight message limit when publishing messages after reconnecting, this is in spite of the check that exists in ClientComms.ReconnectDisconnectedBufferCallback.publishBufferedMessage where there is a specific that will then Yield to other threads if we have hit the window.
The problem is that even with this check, the callback still manages to publish a message that exceeds the max inflight limit.