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

["Todd Lipcon (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KUDU-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197842#comment-16197842 ] 

Todd Lipcon commented on KUDU-1767:
-----------------------------------

I don't think simply rejecting out-of-order writes based on sequence number is doable.

First of all, this would be too strict -- two operations bound for different tablets on the same server would end up with a false ordering and thus cause them to be fully serialized rather than parallel. We depend on parallelism across tablets even if they're on the same server.

Second, I think there would be issues with leader changes. Imagine something like:

- Client sends seqno 1 to TS A
- TS A crashes and so it doesn't yet respond (marks TS A as "down" in its metacache)
- Client sends seqno 2 to TS B
- TS B receives seqno 2 but hasn't yet seen seqno 1 as a replica
- TS B finishes processing the UpdateConsensus RPC from the now-dead TS A and now sees seqno 1 "out of order"

It can't reject seqno 1 at this point because it's already been replicated.

I'm sure it's possible to get stricter semantics, but I think in most cases even if we provided this, clients would end up producing their own variant of this issue. For example, doing a bulk load using Spark or Impala means that many tasks are writing in parallel, and it's not deterministic who "wins" a race when the same row shows up twice.

> 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.4.14#64029)