[
https://issues.apache.org/jira/browse/HADOOP-10389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986295#comment-13986295
]
Colin Patrick McCabe commented on HADOOP-10389:
-----------------------------------------------
bq. I couldn't tell if this had already made it into the hadoop-common build
system?
It's not hooked up to Maven yet, no. We'll use the same method we hook CMake
to the current Maven poms, I think. Shouldn't be too difficult.
bq. I'm assuming this is a preliminary patch? I think that we'll need more test
cases and a valgrind run?
I have run valgrind on it and come up clean. There is one test case here, more
will follow.
bq. I think in the long term the cmake file will need to be cleaned up. I saw a
couple of just hacks (ie find_library(PROTOC_LIB NAMES libprotoc.so HINTS
/opt/protobuf-2.5/lib64/).
Fixed, thanks
bq. Do we need a cap on how large '&reactor->inbox.pending_calls' can be? I'm
concerned that some systems can be intensive enough to cause OOM exceptions.
Also, client side throttling may set good boundaries?
I think the first thing to do is implement RPC timeouts, which we can do in a
follow-on. This should avoid having queues that grow too much, unless the
client is truly unwise about making a ton of calls in a short period.
[~vicaya]: yes, we will do user / group security in a follow-up. I think for
the "plain" auth method, it will be as simple as just filling in the fields in
the header. SASL will be more work. There is definitely lots of work for
branch committers here :)
bq. +1
Will commit to branch. And file follow-ups...
> 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
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)