[
https://issues.apache.org/jira/browse/KUDU-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17258713#comment-17258713
]
ASF subversion and git services commented on KUDU-2011:
-------------------------------------------------------
Commit 5b2287aa3c1a2858f918aec25054eb9ce523572e in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=5b2287a ]
[docs] RPC cancellation is now implemented
This patch updates the documentation on the RPC design in rpc.md,
refreshing the note on the RPC cancellation. Since KUDU-2065 has been
addressed, it's now possible to cancel a remote call using the
RpcController::Cancel() method (follow up JIRAs KUDU-2334 and KUDU-2011
are still open, but the functionality for RPC cancellation is there).
Change-Id: I335b3c0fd965896aff7e1625fd01ae564c050b1a
Reviewed-on: http://gerrit.cloudera.org:8080/16918
Tested-by: Kudu Jenkins
Reviewed-by: Grant Henke <[email protected]>
> Request-side sidecars cannot be safely destroyed on timeout
> -----------------------------------------------------------
>
> Key: KUDU-2011
> URL: https://issues.apache.org/jira/browse/KUDU-2011
> Project: Kudu
> Issue Type: Bug
> Components: rpc
> Reporter: Henry Robinson
> Assignee: Michael Ho
> Priority: Major
>
> If a timeout occurs while sending a request-side sidecar (see KUDU-1866), the
> RPC callback may be invoked before the outbound transfer has been completely
> written.
> This is the last notification from the RPC layer that the caller will get, so
> you might expect them to delete the sidecar payload at that point, but it's
> not safe to do so. In fact, with a slow sender there is no way for the caller
> to know when it's safe to delete the payload. There's no problem for the
> protobuf message data, as it's serialized during the blocking part of an
> async call, and that memory is tied to the lifetime of the outbound call,
> which is managed by the RPC layer.
> Ownership of the sidecar payloads should be shared between caller and the RPC
> layer, so really it's the new {{RpcSidecar::FromSlice}} API that causes the
> problems because ownership is not shared with the {{RpcSidecar}} which does
> have the correct lifetime. I propose removing {{FromSlice}} and having a
> {{FromFaststring(shared_ptr<faststring>)}} variant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)