[
https://issues.apache.org/jira/browse/HDFS-16880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653910#comment-17653910
]
ASF GitHub Bot commented on HDFS-16880:
---------------------------------------
hfutatzhanghb commented on code in PR #5262:
URL: https://github.com/apache/hadoop/pull/5262#discussion_r1060434510
##########
hadoop-hdfs-project/hadoop-hdfs-rbf/src/main/java/org/apache/hadoop/hdfs/server/federation/router/RouterRpcServer.java:
##########
@@ -687,7 +687,7 @@ <T> T invokeAtAvailableNs(RemoteMethod method, Class<T>
clazz)
// If default Ns is present return result from that namespace.
if (!nsId.isEmpty()) {
try {
- return rpcClient.invokeSingle(nsId, method, clazz);
+ return rpcClient.invokeSingle(nsId, method, clazz, "");
Review Comment:
> > Yes，the src is not the dst path, but we can use the src to lookup real
dst path in mount table. Here, we can not execute
this.subclusterResolver.getMountPoints(path);, because the statement is
time-consuming.
>
> From correctness point of view it isn't correct. If `/mount/path` points
to Ns0 `/dir` and we log` /mount/path` in the namenode, it can lead to
confusions if the namenode also has a path named `/mount/path`, If you operate
on `/dir` via router `/mount/path` and if you directly operate on `/mount/path`
on the namenode.
>
> If it has serious performance penalties we need to make it configurable
and then figure out what can be done when the config is disabled.
Hi, @ayushtkn , can we prepend some specific prefix, such as "RBF#src_path:"
to the dir? In this way, we can distinguish RBF scene from direct namenode
scene. What’s your opinion? I am looking forward to your reply and do the next
steps. thanks again~
> modify invokeSingleXXX interface in order to pass actual file src to namenode
> for debug info.
> ---------------------------------------------------------------------------------------------
>
> Key: HDFS-16880
> URL: https://issues.apache.org/jira/browse/HDFS-16880
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: rbf
> Affects Versions: 3.3.4
> Reporter: ZhangHB
> Priority: Major
> Labels: pull-request-available
>
> We found lots of INFO level log like below:
> {quote}2022-12-30 15:31:04,169 INFO org.apache.hadoop.hdfs.StateChange: DIR*
> completeFile: / is closed by
> DFSClient_attempt_1671783180362_213003_m_000077_0_1102875551_1
> 2022-12-30 15:31:04,186 INFO org.apache.hadoop.hdfs.StateChange: DIR*
> completeFile: / is closed by DFSClient_NONMAPREDUCE_1198313144_27480
> {quote}
> It lost the real path of completeFile. Actually this is caused by :
>
> *org.apache.hadoop.hdfs.server.federation.router.RouterRpcClient#invokeSingle(java.lang.String,
> org.apache.hadoop.hdfs.server.federation.router.RemoteMethod)*
> In this method, it instantiates a RemoteLocationContext object:
> *RemoteLocationContext loc = new RemoteLocation(nsId, "/", "/");*
> and then execute: *Object[] params = method.getParams(loc);*
> The problem is right here, becasuse we always use new RemoteParam(), so,
> context.getDest() always return "/"; That's why we saw lots of incorrect logs.
>
> After diving into invokeSingleXXX source code, I found the following RPCs
> classified as need actual src and not need actual src.
>
> *need src path RPC:*
> addBlock、abandonBlock、getAdditionalDatanode、complete
> *not need src path RPC:*
> updateBlockForPipeline、reportBadBlocks、getBlocks、updatePipeline、invokeAtAvailableNs（invoked
> by:
> getServerDefaults、getBlockKeys、getTransactionID、getMostRecentCheckpointTxId、versionRequest、getStoragePolicies）
>
> After changes, the src can be pass to NN correctly.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
