Thanks everyone for discussing and voting for the issue.
Totally 6 +1s for Approach A (include my own +1).
I would like summary voting solution:
- Add extra optional field about client hostname in
RpcHeader#RpcRequestHeaderProto,
- Router set RpcRequestHeader#clientHostname if necessary,
+1 for approach A.
On Thu, 11 Apr 2019, 12:23 pm Akira Ajisaka, wrote:
> The Approach A looks good to me.
>
> Thanks,
> Akira
>
> On Thu, Apr 11, 2019 at 2:30 PM Xiaoqiao He wrote:
> >
> > Hi forks,
> >
> > The current implementation of RBF is not sensitive about data locality,
> > since
Thanx Hexiaoqiao for putting this up.
As already discussed at the JIRA
The Approach A sounds best to me.
-Ayush
> On 11-Apr-2019, at 11:50 PM, Giovanni Matteo Fumarola
> wrote:
>
> +1 on Approach A.
>
>> On Thu, Apr 11, 2019 at 10:30 AM Iñigo Goiri wrote:
>>
>> Thanks Hexiaoqiao for
+1 on Approach A.
On Thu, Apr 11, 2019 at 10:30 AM Iñigo Goiri wrote:
> Thanks Hexiaoqiao for starting the vote.
> As I said in the JIRA, I prefer Approach A.
>
> I wanted to bring a broader audience as this has changes in RBF, HDFS and
> Commons.
> I think adding a new optional field to the
Thanks Hexiaoqiao for starting the vote.
As I said in the JIRA, I prefer Approach A.
I wanted to bring a broader audience as this has changes in RBF, HDFS and
Commons.
I think adding a new optional field to the RPC header should be lightweight
enough.
The idea of passing a proxied client is
The Approach A looks good to me.
Thanks,
Akira
On Thu, Apr 11, 2019 at 2:30 PM Xiaoqiao He wrote:
>
> Hi forks,
>
> The current implementation of RBF is not sensitive about data locality,
> since NameNode could not get real client hostname by invoke
> Server#getRemoteAddress when RPC request
Hi forks,
The current implementation of RBF is not sensitive about data locality,
since NameNode could not get real client hostname by invoke
Server#getRemoteAddress when RPC request forward by Router to NameNode.
Therefore, it will lead to several challenges, for instance,
- a. Client could
