[
https://issues.apache.org/jira/browse/HADOOP-12909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15211745#comment-15211745
]
Steve Loughran commented on HADOOP-12909:
-----------------------------------------
I'll let sanjay handle the architectural issues.
h2. Production code
Regarding the client setup, it's still something I worry about, but it is
workable. I'd recommend those methods are marked as Unstable. Actually, there
aren't any visibility tags on Client and Server at all: I'd recommend @Public,
@Evolving for the whole class, as well as @Unstable for the new methods.
In {{Client.call(RPC.RpcKind rpcKind, Writable rpcRequest)}}
line 1370; warning text includes detail not added to the exception. Can you
assign that extra text to a string and included
{code}
String text = String.format("Error in instantiating Writable %s",
rpcRequest.getClass());
LOG.warn(text, ie)
throw new IOException(text + " " + ie, ie);
{code}
h2. Tests.
* If {{TestIPC.TestServer}} was also made {{AutoCloseable}}, with {{close()}}
calling {{stop()}}, you could use try-with-resources to do all the test
cleanup; potentially make for cleanup/small test cases.
* A couple of your {{assertEquals}} clauses are the wrong way round; expected
must always come first.
* I'd like some text string of failure causes in the {{assertFalse()}} calls.
Imagine the test has failed in a Jenkins run: what extra information would you
need to start debugging the failure.
> Change ipc.Client to support asynchronous calls
> -----------------------------------------------
>
> Key: HADOOP-12909
> URL: https://issues.apache.org/jira/browse/HADOOP-12909
> Project: Hadoop Common
> Issue Type: New Feature
> Components: ipc
> Reporter: Tsz Wo Nicholas Sze
> Assignee: Xiaobing Zhou
> Attachments: HADOOP-12909-HDFS-9924.000.patch,
> HADOOP-12909-HDFS-9924.001.patch, HADOOP-12909-HDFS-9924.002.patch,
> HADOOP-12909-HDFS-9924.003.patch, HADOOP-12909-HDFS-9924.004.patch,
> HADOOP-12909-HDFS-9924.005.patch
>
>
> In ipc.Client, the underlying mechanism is already supporting asynchronous
> calls -- the calls shares a connection, the call requests are sent using a
> thread pool and the responses can be out of order. Indeed, synchronous call
> is implemented by invoking wait() in the caller thread in order to wait for
> the server response.
> In this JIRA, we change ipc.Client to support asynchronous mode. In
> asynchronous mode, it return once the request has been sent out but not wait
> for the response from the server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
