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