[
https://issues.apache.org/jira/browse/KUDU-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15813718#comment-15813718
]
Mike Percy edited comment on KUDU-1767 at 1/10/17 3:29 AM:
-----------------------------------------------------------
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.
Systems that want to write in a particular order 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 a following update to that key while still
maintaining some parallelism at load time.
was (Author: mpercy):
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)
