For more details, see
https://ci-hadoop.apache.org/job/hadoop-qbt-trunk-java11-linux-x86_64/851/
[Apr 22, 2025, 9:50:15 AM] (github) Revert "YARN-11765. Refactor: Move Clock
Class from hadoop-mapreduce-project to hadoop-common-project for Reusability
(#7352) Contributed by Jiandan Yang." (#759
For more details, see
https://ci-hadoop.apache.org/job/hadoop-qbt-trunk-java8-linux-x86_64/1920/
[Apr 22, 2025, 9:50:15 AM] (github) Revert "YARN-11765. Refactor: Move Clock
Class from hadoop-mapreduce-project to hadoop-common-project for Reusability
(#7352) Contributed by Jiandan Yang." (#759
[
https://issues.apache.org/jira/browse/HDFS-12431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsz-wo Sze resolved HDFS-12431.
---
Fix Version/s: 3.5.0
Resolution: Fixed
The pull request is now merged. Thanks, [~zhtttylzz] !
Hello, everyone, so sorry to bother you and I would like to discuss how to
optimize the invoke retry logic of async repsonder when some nameservices are
slow.
Currently, all nameservices share one async responder thread pool which is in
class AsyncRpcProtocolPBUtil.
Think below situation, we
@Xiaoqiao He Thanks very much for responsing.
1. Yes, this proposal is related to RBF and ARR features.
2. Usually, slow nameservices will not affect the performance of other normal
nameservices due to the async handler thread pool. But there exists an
extremely rare situation that retry invo
+ hdfs-dev.
Thanks Haobo for your proposal. As you mentioned above, this may be
related to RBF and ARR features, right?
IMO, it is necessary to improve responder performance, but I am a
little confused about nameservice will slow
down the whole system, The first glance is client or package size
sh
For more details, see
https://ci-hadoop.apache.org/job/hadoop-qbt-branch-2.10-java7-linux-x86_64/1735/
No changes
-1 overall
The following subsystems voted -1:
asflicense hadolint mvnsite pathlen unit
The following subsystems voted -1 but
were configured to be filtered/ignored:
cc
