[
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)
