Re: [DISCUSS] Retire BKJM from trunk?

For Huawei, Vinay/Brahma should know about their usage. I think after QJM stabilized and ready they also adopted to QJM is what I know, but they should know more than me as I left that employer while ago. If no one is using it, It is ok to remove. Regards, Uma On 7/27/16, 9:49 PM, "Rakesh

Re: [DISCUSS] Retire BKJM from trunk?

If I remember correctly, Huawei also adopted QJM component. I hope @Vinay might have discussed internally in Huawei before starting this e-mail discussion thread. I'm +1, for removing the bkjm contrib from the trunk code. Also, there are quite few open sub-tasks under HDFS-3399 umbrella jira,

[jira] [Created] (HDFS-10700) I increase the value of the GC_OPTS on namenode. After I modified the value ,namenode start failed.

Liu Guannan created HDFS-10700: -- Summary: I increase the value of the GC_OPTS on namenode. After I modified the value ,namenode start failed. Key: HDFS-10700 URL: https://issues.apache.org/jira/browse/HDFS-10700

[jira] [Created] (HDFS-10699) Log object instance get incorrectly in TestDFSAdmin

Yiqun Lin created HDFS-10699: Summary: Log object instance get incorrectly in TestDFSAdmin Key: HDFS-10699 URL: https://issues.apache.org/jira/browse/HDFS-10699 Project: Hadoop HDFS Issue Type:

Re: Apply for "assign to me" permission.

Done. Thanks for your interest in contributing to Hadoop. On 7/27/16, 6:47 PM, "hufh" wrote: Hi guys, I have opened a JIRA(https://issues.apache.org/jira/browse/HDFS-10690) and want to fix it, but i can't assign it to myself, anyone can give me a hand?

Apply for "assign to me" permission.

Hi guys, I have opened a JIRA(https://issues.apache.org/jira/browse/HDFS-10690) and want to fix it, but i can't assign it to myself, anyone can give me a hand? Thanks a lot! Fenghua

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 (binding) - downloaded both source and binary tarballs and verified the signatures - set up a pseudo-distributed cluster - ran some simple mapreduce jobs - checked the basic web UI Sangjin On Wed, Jul 27, 2016 at 12:57 PM, John Zhuge wrote: > +1 (non-binding) > > -

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Hi Junping, thanks for sharing your thoughts, inline, On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 wrote: > Thanks Vinod for bringing up this topic for discussion. I share the same > concern here from my previous experience and I doubt some simple rules > proposed below could

Re: [DISCUSS] Retire BKJM from trunk?

+ Rakesh and Uma Rakesh and Uma might have a better idea on this. I think Huawei was using it when Rakesh and Uma worked there. - Sijie On Wed, Jul 27, 2016 at 12:06 PM, Chris Nauroth wrote: > I recommend including the BookKeeper community in this discussion. I’ve >

[jira] [Resolved] (HDFS-10698) Test org.apache.hadoop.cli.TestHDFSCLI fails in trunk

[ https://issues.apache.org/jira/browse/HDFS-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei-Chiu Chuang resolved HDFS-10698. Resolution: Duplicate thx Youngjun for filing the jira. This is a dup of HDFS-10696 where a

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 (non-binding) - Build source with Java 1.8.0_101 on Centos 7.2 with native - Build source with Java 1.7.0_79 on Mac - Verify license and notice using the shell script in HADOOP-13374 - Deploy a pseudo cluster - Run basic dfs, distcp, ACL, webhdfs commands - Run MapReduce workcount and pi

[jira] [Created] (HDFS-10698) Test org.apache.hadoop.cli.TestHDFSCLI fails in trunk

Yongjun Zhang created HDFS-10698: Summary: Test org.apache.hadoop.cli.TestHDFSCLI fails in trunk Key: HDFS-10698 URL: https://issues.apache.org/jira/browse/HDFS-10698 Project: Hadoop HDFS

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as >> a.b.c versions, with alpha1 being the a.b.0 release. >> > > Once 3.0.0 GA goes out, a user would want to see the diff from the latest > 2.x.0 release (say 2.9.0). > > Are you suggesting 3.0.0 GA would have c = 5 (say)

Re: [DISCUSS] Retire BKJM from trunk?

I recommend including the BookKeeper community in this discussion. I’ve added their user@ and dev@ lists to this thread. I do not see BKJM being used in practice. Removing it from trunk would be attractive in terms of less code for Hadoop to maintain and build, but if we find existing users

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 (binding) - Downloaded binary tarball - verified signatures - setup pseudo cluster - ran some of the example jobs, clicked around the UI a bit - Robert On Mon, Jul 25, 2016 at 3:28 PM, Jason Lowe wrote: > +1 (binding) > - Verified signatures and digests-

Re: Improving recovery performance for degraded reads

Hi Roy, (a) In your last email, I am sure you meant => "... submitting read requests to fetch "any" (instead of all) the 'k' chunk (out of k+m-x surviving chunks) ? Do you have any optimization in place to decide which data-nodes will be part of those "k" ? Answer:- I hope you know

[jira] [Reopened] (HDFS-8224) Any IOException in DataTransfer#run() will run diskError thread even if it is not disk error

[ https://issues.apache.org/jira/browse/HDFS-8224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rushabh S Shah reopened HDFS-8224: -- Saw one more occurrence of this bug. We should atleast add this block to the front of the scanning

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Vinod for bringing up this topic for discussion. I share the same concern here from my previous experience and I doubt some simple rules proposed below could make life easier. > The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix versions. > Allen's historical perspective is

Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

For more details, see https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/115/ [Jul 26, 2016 1:30:02 PM] (stevel) Revert "HDFS-10668. Fix intermittently failing UT [Jul 26, 2016 1:53:37 PM] (kai.zheng) HADOOP-13041. Adding tests for coder utilities. Contributed by Kai [Jul 26, 2016

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Inline. > 1) Set the fix version for all a.b.c versions, where c > 0. > 2) For each major release line, set the lowest a.b.0 version. > Sounds reasonable. > > The -alphaX versions we're using leading up to 3.0.0 GA can be treated as > a.b.c versions, with alpha1 being the a.b.0 release. >

[jira] [Created] (HDFS-10696) TestHDFSCLI fails

Akira Ajisaka created HDFS-10696: Summary: TestHDFSCLI fails Key: HDFS-10696 URL: https://issues.apache.org/jira/browse/HDFS-10696 Project: Hadoop HDFS Issue Type: Bug Components:

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

Thanks Andrew for sharing your thoughts, It looks better if we can put multiple versions on the fix version, with that we can at least do some queries on JIRA to check the issues like "in branch-2.6.5 but not in branch-2.7.4". I still have a couple of questions: *1) How CHANGES.txt (or release

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> I think I understand a bit better, though now I ask how this date is > different from the release date. OIC. I also assume that the freezing branch cannot include the changes between freezing date and the release date. This is for strict ordering to ensure which is the newer. If we have lots

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

I think I understand a bit better, though now I ask how this date is different from the release date. Based on the HowToRelease instructions, we set the release date to when the release vote passes. So, start of release vote vs. end of release vote doesn't seem that different, and these dates are

[DISCUSS] Retire BKJM from trunk?

Hi All, BKJM was Active and made much stable when the NameNode HA was implemented and there was no QJM implemented. Now QJM is present and is much stable which is adopted by many production environment. I wonder whether it would be a good time to retire BKJM from trunk? Are there

Re: [DISCUSS] Release numbering semantics with concurrent (>2) releases [Was Setting JIRA fix versions for 3.0.0 releases]

> Andrew: I bet many would assume it's the release date, like how Ubuntu releases are numbered. Good point. Maybe I confuse you because of lack of explanation. I assume that "branch-cut off timing" mean the timing of freezing branch like when starting the release vote. It's because that the