[
https://issues.apache.org/jira/browse/KUDU-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702730#comment-15702730
]
Todd Lipcon commented on KUDU-1761:
-----------------------------------
I agree that the exactly-once stuff should have no bearing on request ordering;
it's only meant to provide idempotency, not any other cross-request guarantees,
and I think it would be a mistake to try to bend it into providing some kind of
serialization order (for the same reason David mentioned).
My vote is that we commit a change to the client API docs that makes this
behavior more clear -- probably on the 'Flush' API and on the docs for the
different flush modes. It's a slightly surprising bit of semantics, so worth
noting, but I don't think it's worth prioritizing a fix at this point in time.
> Flaky tablet_history_gc-itest due to interleaving of concurrent client flushes
> ------------------------------------------------------------------------------
>
> Key: KUDU-1761
> URL: https://issues.apache.org/jira/browse/KUDU-1761
> Project: Kudu
> Issue Type: Bug
> Components: client, test
> Affects Versions: 1.1.0
> Reporter: Mike Percy
>
> It appears that tablet_history_gc-itest is flaky due to interleaving of
> client operations when automatic flush is enabled. The test is particularly
> susceptible if an async flush is triggered after each operation.
> The issue becomes more apparent when there are two updates to the same row in
> quick succession, and an async flush is triggered after each one. Sometimes
> the 2nd update is applied first on the server, then overwritten by the 1st
> update, even though it was applied first to the client session. This
> concurrency race may manifest randomly in response to thread and network
> timing latencies.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
