[
https://issues.apache.org/jira/browse/KUDU-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706323#comment-15706323
]
Mike Percy commented on KUDU-1767:
----------------------------------
I think most people would expect that the order that they put their updates
into the same client is the order that they are applied.
For example, if you do this:
{code}
update rowid=5 value=1
update rowid=5 value=2
{code}
And then you flush, and it returns OK, but rowid=5 actually contains the
value=1 after quiescing, then it appears that you have lost data and that the
operations were erroneously misordered.
> Reordering of client operations from the same KuduSession is possible
> ---------------------------------------------------------------------
>
> Key: KUDU-1767
> URL: https://issues.apache.org/jira/browse/KUDU-1767
> Project: Kudu
> Issue Type: Bug
> Components: client, tablet
> Affects Versions: 1.1.0
> Reporter: Mike Percy
> Priority: Critical
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
