[jira] [Created] (HADOOP-10490) TestMapFile and TestBloomMapFile leak file descriptors.

Chris Nauroth created HADOOP-10490: -- Summary: TestMapFile and TestBloomMapFile leak file descriptors. Key: HADOOP-10490 URL: https://issues.apache.org/jira/browse/HADOOP-10490 Project: Hadoop Common

[jira] [Created] (HADOOP-10489) UserGroupInformation#getTokens and UserGroupInformation#addToken can lead to ConcurrentModificationException

Jing Zhao created HADOOP-10489: -- Summary: UserGroupInformation#getTokens and UserGroupInformation#addToken can lead to ConcurrentModificationException Key: HADOOP-10489 URL: https://issues.apache.org/jira/browse/HADO

Re: [VOTE] Release Apache Hadoop 2.4.0

+1(non-binding) download source code compile successfully run wordcount and loadgen without problem On Tue, Apr 8, 2014 at 11:11 PM, Tsuyoshi OZAWA wrote: > Hi Arun, > > I apologize for the late response. > If the problems are recognized correctly, +1 for the release(non-binding). > > * Ran exam

Re: Plans of moving towards JDK7 in trunk

A bit of a different angle. As the bottom of the stack Hadoop has to be conservative in adopting things, but it should not preclude consumers of Hadoop (downstream projects and Hadoop application developers) to have additional requirements such as a higher JDK API than JDK6. Hadoop 2.x should sti

Re: Plans of moving towards JDK7 in trunk

On Thu, Apr 10, 2014 at 6:49 AM, Raymie Stata wrote: > I think the problem to be solved here is to define a point in time > when the average Hadoop contributor can start using Java7 dependencies > in their code. > > The "use Java7 dependencies in trunk(/branch3)" plan, by itself, does > not solve

Re: Plans of moving towards JDK7 in trunk

On Thu, Apr 10, 2014 at 1:11 AM, Steve Loughran wrote: > On 9 April 2014 23:52, Eli Collins wrote: > > > > > > > For the sake of this discussion we should separate the runtime from > > the programming APIs. Users are already migrating to the java7 runtime > > for most of the reasons listed below

Re: DISCUSS: use SLF4J APIs in new modules?

+1 to use slf4j. I would actually vote for (1) new modules must-use, (2) new classes in existing modules are strongly recommended to use, (3) existing classes can switch to. That would take us closer to using slf4j everywhere faster. On Thu, Apr 10, 2014 at 8:17 AM, Alejandro Abdelnur wrote: > +

Re: DISCUSS: use SLF4J APIs in new modules?

+1 pn slf4j. one thing Jay, the issues with log4j will still be there as log4j will still be under the hood. thx Alejandro (phone typing) > On Apr 10, 2014, at 7:35, Andrew Wang wrote: > > +1 from me, it'd be lovely to get rid of all those isDebugEnabled checks. > > >> On Thu, Apr 10, 20

Re: DISCUSS: use SLF4J APIs in new modules?

+1 from me, it'd be lovely to get rid of all those isDebugEnabled checks. On Thu, Apr 10, 2014 at 4:13 AM, Jay Vyas wrote: > Slf4j is definetly a great step forward. Log4j is restrictive for complex > and multi tenant apps like hadoop. > > Also the fact that slf4j doesn't use any magic when bi

[jira] [Resolved] (HADOOP-10382) Add Apache Tez to the Hadoop homepage as a related project

[ https://issues.apache.org/jira/browse/HADOOP-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun C Murthy resolved HADOOP-10382. Resolution: Fixed I just committed this. > Add Apache Tez to the Hadoop homepage as a re

Re: Plans of moving towards JDK7 in trunk

I think the problem to be solved here is to define a point in time when the average Hadoop contributor can start using Java7 dependencies in their code. The "use Java7 dependencies in trunk(/branch3)" plan, by itself, does not solve this problem. The average Hadoop contributor wants to see their

Re: DISCUSS: use SLF4J APIs in new modules?

Slf4j is definetly a great step forward. Log4j is restrictive for complex and multi tenant apps like hadoop. Also the fact that slf4j doesn't use any magic when binding to its log provider makes it way easier to swap out its implementation then tools of the past. > On Apr 10, 2014, at 2:16 AM,

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

See Changes: [tucu] HADOOP-10428. JavaKeyStoreProvider should accept keystore password via configuration falling back to ENV VAR. (tucu) [vinodkv] YARN-1910. Fixed a race condition in TestAMRMTokens that causes the test to fail m

DISCUSS: use SLF4J APIs in new modules?

If we're thinking of future progress, here's a little low-level one: adopt SLF4J as the API for logging 1. its the new defacto standard of logging APIs 2. its a lot better than commons-logging with on demand Inline string expansion of varags arguments. 3. we already ship it, as jetty

Re: Plans of moving towards JDK7 in trunk

On 9 April 2014 23:52, Eli Collins wrote: > > > For the sake of this discussion we should separate the runtime from > the programming APIs. Users are already migrating to the java7 runtime > for most of the reasons listed below (support, performance, bugs, > etc), and the various distributions ce