[
https://issues.apache.org/jira/browse/KUDU-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-1767:
--------------------------------
Description:
It is possible for client operations written via the same KuduSession in
AUTO_BACKGROUND_FLUSH mode to be reordered on the server side. 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. In essence,
multiple RPCs sent from the client to the server might be pending concurrently,
and the order of processing them at the server side is affected by:
* OS scheduling of multiple RPC worker threads that pick up their work from the
server's RPC queue
* intermittent failure of an RPC (e.g. due to SERVICE_UNAVAILABLE because of
memory pressure or similar) followed by automatic retrial of the RPC by the
Kudu client library
NOTE: In Kudu C++ client API, the reordering is also possible if using
{{KuduSession::FlushAsync()}} in MANUAL_FLUSH mode. In Kudu Java client API
the reordering is also possible in MANUAL_FLUSH mode if using
{{AsyncKuduSession}}. Meanwhile, using {{KuduSession::Flush()}} in Kudu C++
client API and synchronous-style {{KuduSession}} API in Kudu Java client may
not result in reordering of write operations in MANUAL_FLUSH mode.
was:
It is possible for client operations written via the same KuduSession to be
reordered on the server side in AUTO_BACKGROUND_FLUSH mode. 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.
NOTE: In Kudu C++ client API, the reordering is also possible if using
{{KuduSession::FlushAsync()}} in MANUAL_FLUSH mode. In Kudu Java client API
the reordering is also possible in MANUAL_FLUSH mode if using
{{AsyncKuduSession}}. Meanwhile, using {{KuduSession::Flush()}} in Kudu C++
client API and synchronous-style {{KuduSession}} API in Kudu Java client may
not result in reordering of write operations in MANUAL_FLUSH mode.
> 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: Major
>
> It is possible for client operations written via the same KuduSession in
> AUTO_BACKGROUND_FLUSH mode to be reordered on the server side. 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. In essence,
> multiple RPCs sent from the client to the server might be pending
> concurrently, and the order of processing them at the server side is affected
> by:
> * OS scheduling of multiple RPC worker threads that pick up their work from
> the server's RPC queue
> * intermittent failure of an RPC (e.g. due to SERVICE_UNAVAILABLE because of
> memory pressure or similar) followed by automatic retrial of the RPC by the
> Kudu client library
> NOTE: In Kudu C++ client API, the reordering is also possible if using
> {{KuduSession::FlushAsync()}} in MANUAL_FLUSH mode. In Kudu Java client API
> the reordering is also possible in MANUAL_FLUSH mode if using
> {{AsyncKuduSession}}. Meanwhile, using {{KuduSession::Flush()}} in Kudu C++
> client API and synchronous-style {{KuduSession}} API in Kudu Java client may
> not result in reordering of write operations in MANUAL_FLUSH mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
