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

Mike Percy commented on KUDU-1767:
----------------------------------

Pulling in some comments from KUDU-1761.

>From [~dralves]:

{quote}
You're suggesting that EO semantics should enforce write order but my point 
was: how is the server supposed to know that the client requires order 
enforcement versus just trying to do multiple writes at the same time?

There's a "happened before" relationship here that we're expecting to be 
enforced and that I think should be enforced in the client, outside of EO 
semantics.
{quote}

>From [~tlipcon]:

{quote}
I agree that the exactly-once stuff should have no bearing on request ordering; 
it's only meant to provide idempotency, not any other cross-request guarantees, 
and I think it would be a mistake to try to bend it into providing some kind of 
serialization order (for the same reason David mentioned).

My vote is that we commit a change to the client API docs that makes this 
behavior more clear – probably on the 'Flush' API and on the docs for the 
different flush modes. It's a slightly surprising bit of semantics, so worth 
noting, but I don't think it's worth prioritizing a fix at this point in time.
{quote}


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

Reply via email to