Re: [VOTE] Release Apache Hadoop 2.4.0

+1 for another rc. There have been quite a few issues found (handful marked blocker) and this is only the first release candidate, seems like the point of having multiple release candidates is to iterate with another one that addresses the major issues found with the previous one. On Fri, Apr 4,

Re: [VOTE] Release Apache Hadoop 2.4.0

I built the release from the rc tag, enabled timeline history service and ran a sleep job on a pseudo-distributed cluster. I encourage another rc, for 2.4.0 (non-binding) 1) Despite the discussion on YARN-1701, timeline AHS still sets yarn.timeline-service.generic-application-history.fs-history-s

Re: Plans of moving towards JDK7 in trunk

So, you want to compile hdfs/yarn/mapred clients (and hadoop-common and hadoop-auth) with JDK6 and the rest with JDK7? On Fri, Apr 4, 2014 at 3:15 PM, Haohui Mai wrote: > I'm referring to the later case. Indeed migrating JDK7 for branch-2 is more > difficult. > > I think one reasonable approach

Re: Plans of moving towards JDK7 in trunk

bq. It might not be as clear cut... Totally agree. I think the key is that we can do the work in an incremental way. We can only introduce JDK7 dependency on the server side. In order to do this we need to separate the client-side code to separate jars. I've already proposed to create a hdfs-clien

Re: Plans of moving towards JDK7 in trunk

Please don't forget the mac os build on JDK 7. :) On Fri, Apr 4, 2014 at 3:15 PM, Haohui Mai wrote: > I'm referring to the later case. Indeed migrating JDK7 for branch-2 is more > difficult. > > I think one reasonable approach is to put the hdfs / yarn clients into > separate jars. The client-s

Re: Plans of moving towards JDK7 in trunk

I'm referring to the later case. Indeed migrating JDK7 for branch-2 is more difficult. I think one reasonable approach is to put the hdfs / yarn clients into separate jars. The client-side jars can only use JDK6 APIs, so that downstream projects running on top of JDK6 continue to work. The HDFS/Y

Re: Plans of moving towards JDK7 in trunk

Haohui, Is the idea to compile/test with JDK7 and recommend it for runtime and stop there? Or to start using JDK7 API stuff as well? If the later is the case, then backporting stuff to branch-2 may break and patches may have to be refactored for JDK6. Given that branch-2 got GA status not so long

Plans of moving towards JDK7 in trunk

Hi, There have been multiple discussions on deprecating supports of JDK6 and moving towards JDK7. It looks to me that the consensus is that now hadoop is ready to drop the support of JDK6 and to move towards JDK7. Based on the consensus, I wonder whether it is a good time to start the migration.

Re: [VOTE] Release Apache Hadoop 2.4.0

Thanks for helping Tsuyoshi. Pls mark them as Blockers and set the fix-version to 2.4.1. Thanks again. Arun > On Apr 3, 2014, at 11:38 PM, Tsuyoshi OZAWA wrote: > > Hi, > > Updated a test result log based on the result of 2.4.0-rc0: > https://gist.github.com/oza/9965197 > > IMO, there are

[jira] [Created] (HADOOP-10463) Bring RawLocalFileSystem test coverage to 100%

jay vyas created HADOOP-10463: - Summary: Bring RawLocalFileSystem test coverage to 100% Key: HADOOP-10463 URL: https://issues.apache.org/jira/browse/HADOOP-10463 Project: Hadoop Common Issue Type

Build failed in Jenkins: Hadoop-Common-trunk #1089

See Changes: [kihwal] Fixing an error in CHANGES.txt [jeagles] HADOOP-10454. Provide FileContext version of har file system. (Kihwal Lee via jeagles) [zjshen] MAPREDUCE-5818. Added "hsadmin" command into mapred.cmd. Contributed