[
https://issues.apache.org/jira/browse/HADOOP-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14386708#comment-14386708
]
Yi Liu commented on HADOOP-10300:
---------------------------------
{code}
public void sendResponse() throws IOException {
int count = responseWaitCount.decrementAndGet();
assert count >= 0 : "response has already been sent";
if (count == 0) {
if (rpcResponse == null) {
// needed by postponed operations to indicate an exception has
// occurred. it's too late to re-encode the response so just
// drop the connection. unlikely to occur in practice but in tests
connection.close();
} else {
connection.sendResponse(this);
}
}
}
{code}
In real case, {{rpcResponse}} has value before {{sendResponse}}, so it seems
{{if (rpcResponse == null)}} will not happen. Can we remove
{{connection.close()}} and modify the test which makes this happen?
> Allowed deferred sending of call responses
> ------------------------------------------
>
> Key: HADOOP-10300
> URL: https://issues.apache.org/jira/browse/HADOOP-10300
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: ipc
> Affects Versions: 2.0.0-alpha, 3.0.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: HADOOP-10300.patch, HADOOP-10300.patch
>
>
> RPC handlers currently do not return until the RPC call completes and
> response is sent, or a partially sent response has been queued for the
> responder. It would be useful for a proxy method to notify the handler to
> not yet the send the call's response.
> An potential use case is a namespace handler in the NN might want to return
> before the edit log is synced so it can service more requests and allow
> increased batching of edits per sync. Background syncing could later trigger
> the sending of the call response to the client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
