[
https://issues.apache.org/jira/browse/KUDU-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696524#comment-15696524
]
David Alves commented on KUDU-1761:
-----------------------------------
Right, that's what AUTO_FLUSH_BACKGROUND does under the covers.
You're suggesting that EO semantics should enforce write order but my point
was: how is the server supposed to know that the client requires order
enforcement versus just trying to do multiple writes at the same time?
There's a "happened before" relationship here that we're expecting to be
enforced and that I think should be enforced in the client, outside of EO
semantics.
> 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)
