[
https://issues.apache.org/jira/browse/KUDU-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15693985#comment-15693985
]
David Alves commented on KUDU-1761:
-----------------------------------
You're right that EO works per-request and does nothing to enforce request
ordering, it works on a per-request basis. This seems the right abstraction
level to me though.
It's likely that we don't enforce ordering of _successful completion_ of
flushes with a mix of background and foreground flushes like this.
What would be the right semantics here? A foreground flush should first make
sure a background one is complete (not just "started" first), no? Does that
happen?
I guess this hypothesis should be super simple to prove, just disable auto
flush background and see if the bug persists.
> 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)
