Re: [DISCUSSION] Create a branch to work on non-blocking access to HDFS

Hi Stack, Why don’t we look at the design of what is being proposed? Let us post the design to HDFS-9924 and then if needed, by all means let us open a new Jira. That will make it easy to understand the context if someone is looking at HDFS-9924. I personally believe that it should be the

[jira] [Created] (HDDS-17) Add node to container map class to simplify state in SCM

Anu Engineer created HDDS-17: Summary: Add node to container map class to simplify state in SCM Key: HDDS-17 URL: https://issues.apache.org/jira/browse/HDDS-17 Project: Hadoop Distributed Data Store

Re: [DISCUSSION] Create a branch to work on non-blocking access to HDFS

Will prepare a design doc soon to roughly describe the things we want to do and how we plan to do it, and also the undecided things, such as how to support fan-out. Thanks. 2018-05-04 4:54 GMT+08:00 Anu Engineer : > Hi St.ack/Wei-Chiu, > > It is very kind of St.Ack to

[jira] [Created] (HDFS-13526) Use TimeoutScheduler in RaftClientImpl

Tsz Wo Nicholas Sze created HDFS-13526: -- Summary: Use TimeoutScheduler in RaftClientImpl Key: HDFS-13526 URL: https://issues.apache.org/jira/browse/HDFS-13526 Project: Hadoop HDFS Issue

Re: [DISCUSSION] Create a branch to work on non-blocking access to HDFS

Hi St.ack/Wei-Chiu, It is very kind of St.Ack to bring this question to HDFS Dev. I think this is a good feature to have. As for the branch question, HDFS-9924 branch is already open, we could just use that and I am +1 on adding Duo as a branch committer. I am not familiar with HBase code

Apache Hadoop qbt Report: trunk+JDK8 on Windows/x64

For more details, see https://builds.apache.org/job/hadoop-trunk-win/456/ [May 2, 2018 3:49:12 PM] (jhc) HDFS-11807. libhdfs++: Get minidfscluster tests running under valgrind. [May 2, 2018 6:33:31 PM] (eyang) YARN-8209. Fixed NPE in Yarn Service deletion. Contributed [May 2, 2018

Re: [DISCUSSION] Create a branch to work on non-blocking access to HDFS

Given that HBase 2 uses async output by default, the way that code is maintained today in HBase is not sustainable. That piece of code should be maintained in HDFS. I am +1 as a participant in both communities. On Thu, May 3, 2018 at 9:14 AM, Stack wrote: > Ok with you lot if

[DISCUSSION] Create a branch to work on non-blocking access to HDFS

Ok with you lot if a few of us open a branch to work on a non-blocking HDFS client? Intent is to finish up the old issue "HDFS-9924 [umbrella] Nonblocking HDFS Access". On the foot of this umbrella JIRA is a proposal by the heavy-lifter, Duo Zhang. Over in HBase, we have a limited async DFS