Description
It is possible for client operations written via the same KuduSession to be reordered on the server side in MANUAL_FLUSH and AUTO_BACKGROUND_FLUSH modes. This violates our desired consistency guarantees.
This may occur because we allow concurrent flushes from the client for throughput reasons and there is nothing enforcing the well-ordering of lock acquisition from a single client session on the server side.
Attachments
Issue Links
- blocks
-
KUDU-1761 Flaky tablet_history_gc-itest due to interleaving of concurrent client flushes
- Resolved
- relates to
-
KUDU-1841 Add a client write mode like AUTO_BACKGROUND_FLUSH + data dependencies
- Open
-
KUDU-352 Decide on and implement within-batch ordering for client API
- Resolved
-
KUDU-2261 flush responses' order should match the order we call apply
- Resolved
- links to
Is this consistency guarantee documented? I was not under the impression that the C++ or Java clients guaranteed this. It really hurts parallelism to do so (only one batch can be in flight to a tablet server at once). Additionally its not that strong of a guarantee when you consider that rows falling in separate tablets absolutely do not have this guarantee.