devserver: Fix handling of stale / max update responses
This fixes two shortcomings related to handling of multiple concurrent
update requests:
1) Devserver would update the number of requests handled as soon as
a requests was received, instead of prior to returning the response.
Since obtaining the response could take a while (e.g. request to
a remote devserver over a flaky network connection), the client might
time out and send another request, which would be unjustly rejected.
Further, the checking and updating of the counter was not atomic, so
race conditions might have occurred.
These are fixed by moving the counter update to the latest point
possible, and doing it atomically.
2) When a response takes a while to handle, the client might time out
and send a new request. In the event this happens, we want the server
to realize that it should not return a response for the first request
nor count it against the maximum allowed.
This problem is not easy to fix completely, as there is no
deterministic way to know whether or not the client has timed out
(keep in mind that the max-allowed mechanism is a simplistic
workaround for a more elaborate rule-based response mechanism, for
testing purposes). We therefore *minimize* the risk by checking, as
close as possible to where we "commit" to sending a response, whether
a newer request was received. There is still a small chance that
a unique and rare timing of events will cause this problem to
surface.
BUG=chromium:321272
TEST=Unit tests.
Change-Id: I2e9e31b3e9c8c28d8d3e39c0c7d342c102243433
Reviewed-on: https://chromium-review.googlesource.com/179083
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>
1 file changed
