[
https://issues.apache.org/jira/browse/KUDU-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011115#comment-16011115
]
Todd Lipcon commented on KUDU-2011:
-----------------------------------
That solution still requires the caller to be aware of the idea that it can't
reuse the same RpcSidecar object after a timeout, right?
I was trying to think if there is any API by which we can ensure that the
caller "moves" the sidecar into the RPC, and then later has to explicitly
"release" it back to caller-owned. In that "release" call, we could return NULL
or a bad status in the case that the sidecar is still in use by the RPC system
(eg after the edge case described above).
For example, something like:
{code}
class RpcController {
void AddSidecar(unique_ptr<RpcSidecar> foo);
// release any previously set sidecars back to the caller. If the sidecars
are still in use by the RPC
// system, this may return Status::IllegalState.
// NOTE: even if an RPC is complete (i.e its callback has been called) it is
possible for this to return IllegalState,
// (... describe the case of Timeout mid-send)
Status ReleaseSidecars(vector<unique_ptr<RpcSidecar>>* sidecars);
}
{code}
Then in the normal case, you'd get the RPC success, and release the sidecars
for reuse. On an error, you can release for reuse with the possibility that
they can't be released.
> 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
> Reporter: Henry Robinson
> Assignee: Henry Robinson
>
> 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
(v6.3.15#6346)
