[
https://issues.apache.org/jira/browse/HADOOP-10389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995429#comment-13995429
]
Colin Patrick McCabe commented on HADOOP-10389:
-----------------------------------------------
bq. 1. to my understanding, rpc client should have a map<callid, call> to
record all unfinished calls, but I could not find any code assigning
callids(only make them 0) and manage unfinished calls, could you help me
located those logic?
Good question. We should be using incrementing call IDs like the Java client
does, but this is not implemented yet, as you pointed out.
You probably already know this, but I guess I ought to comment here... The
rationale behind call id in general is that in some future version of the Java
RPC system, we may want to allow multiple calls to be "in flight" at once.
Then, the server could send back a response, and tag it with the appropriate
"call id" of the call in flight. However, this is not implemented currently in
the Java RPC server, as I understand. So it's difficult to test on the C
client.
Regardless, I agree that we should implement this.
bq. 2. in the demo namenode-rpc-unit, I see each proxy only have one call(the
current call), does this mean client can only call one rpc at the same time?
No. The client can make multiple calls at once by using multiple proxies.
bq. If so probably every rpc call will need it's own rpc_proxy, from users
standing point, they may want what java's interface, multi-thread can
concurrently call one proxy, this is very common in hdfs client.
The users won't be using proxies... only the native HDFS client has to deal
with them. From the library user's perspective, they are calling {{hdfsOpen}},
{{hdfsClose}}, etc. etc.
bq. 3. hrpc_proxy.call belongs to hrpc_proxy, but in hrpc_proxy_start, the call
is passed to reactor->inbox.pending_calls, which may have longer life circle
than hrpc_proxy, so there may be protential bug in hrpc_proxy.call?
There's no bug. You just can't de-allocate the proxy while it is in use. This
problem can only be solved by garbage collection or memory management of some
form, which C doesn't have. I will add a comment to {{proxy.h}} to make this
requirement clearer.
> Native RPCv9 client
> -------------------
>
> Key: HADOOP-10389
> URL: https://issues.apache.org/jira/browse/HADOOP-10389
> Project: Hadoop Common
> Issue Type: Sub-task
> Affects Versions: HADOOP-10388
> Reporter: Binglin Chang
> Assignee: Colin Patrick McCabe
> Attachments: HADOOP-10388.001.patch, HADOOP-10389.002.patch,
> HADOOP-10389.004.patch, HADOOP-10389.005.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)