[jira] [Resolved] (KUDU-1767) Reordering of client operations from the same KuduSession is possible

["Mike Percy (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Percy resolved KUDU-1767.
------------------------------
       Resolution: Won't Fix
    Fix Version/s: n/a

After discussing this issue with a couple of folks, I am marking this issue Won't Fix for the following reasons:

# This behavior does not violate strict serializability because we are talking about operations that occur simultaneously from Kudu's perspective.
# There are workarounds for the observed behavior.

For systems that want to write in a particular order, then can choose to flush one batch at a time to avoid reordering. If single-key ordering conflicts are the primary concern, care can also be taken by client programs to flush an update to a single key before apply()ing the following update to that key.

> 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
>             Fix For: n/a
>
>
> 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)