[ 
https://issues.apache.org/jira/browse/HDFS-15630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17218255#comment-17218255
 ] 

Chengwei Wang edited comment on HDFS-15630 at 10/21/20, 12:00 PM:
------------------------------------------------------------------

[~elgoiri] [~ferhui], Thanks for comments.

After careful thought, this issue should be divided into 2 parts.
 # transfer the required thread local context to worker threads to avoid client 
ip and origin context lost.
 # append client ip to caller context only if it's absent to avoid client ip 
duplicated.

To transfer context, it's better to set thread local variables directly rather 
than use method params. Just like this:
{code:java}
  callables.add(
     () -> {
     transferThreadLocalContext(originCall, originContext);
     return invokeMethod(ugi, namenodes, proto, m, paramList);
  });
  private void transferThreadLocalContext(
     final Call originCall, final CallerContext originContext) {
     Server.getCurCall().set(originCall);
    CallerContext.setCurrent(originContext);
  }
{code}
 With these required context, we can always get client ip and caller context 
from thread local, and append client ip to caller context only if it’s absent. 

Submit patch v005 [^HDFS-15630.005.patch], could you please take a look?


was (Author: smarthan):
[~elgoiri] [~ferhui], Thanks for comments.

After careful thought, this issue should be divided into 2 parts.
 # transfer the required thread local context to worker threads to avoid client 
ip and origin context lost.
 # append client ip to caller context only if it's absent to avoid client ip 
duplicated.

To transfer context, I think it's better to set thread local variables directly 
rather than use method params. Just like this:
{code:java}
  callables.add(
     () -> {
     transferThreadLocalContext(originCall, originContext);
     return invokeMethod(ugi, namenodes, proto, m, paramList);
  });
  private void transferThreadLocalContext(
     final Call originCall, final CallerContext originContext) {
     Server.getCurCall().set(originCall);
    CallerContext.setCurrent(originContext);
  }
{code}
 With these required context, we can always get client ip and caller context 
from thread local, and append client ip to caller context only if it’s absent. 

Submit patch v005 [^HDFS-15630.005.patch], could you please take a look?

> RBF: Fix wrong client IP info in CallerContext when requests mount points 
> with multi-destinations.
> --------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-15630
>                 URL: https://issues.apache.org/jira/browse/HDFS-15630
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: rbf
>            Reporter: Chengwei Wang
>            Assignee: Chengwei Wang
>            Priority: Major
>         Attachments: HDFS-15630.001.patch, HDFS-15630.002.patch, 
> HDFS-15630.003.patch, HDFS-15630.004.patch, HDFS-15630.005.patch, 
> HDFS-15630.test.patch
>
>
> There are two issues about client IP info in CallerContext when we try to 
> request mount points with multi-destinations.
>  # the clientIp would duplicate in CallerContext when 
> RouterRpcClient#invokeSequential.
>  # the clientIp would miss in CallerContext when 
> RouterRpcClient#invokeConcurrent. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to