[jira] [Resolved] (HADOOP-9597) FileSystem open() API is not clear if FileNotFoundException is throw when the path does not exist

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas resolved HADOOP-9597.
-

Resolution: Invalid

 FileSystem open() API is not clear if FileNotFoundException is throw when the 
 path does not exist
 -

 Key: HADOOP-9597
 URL: https://issues.apache.org/jira/browse/HADOOP-9597
 Project: Hadoop Common
  Issue Type: Improvement
  Components: documentation, fs
Affects Versions: 2.0.4-alpha
Reporter: Jerry He
Priority: Minor
 Fix For: 2.0.4.1-alpha


 The current FileSystem open() method throws a generic IOException in its API 
 specification.
 Some FileSystem implementations (DFS, RawLocalFileSystem ...) throws more 
 specific FileNotFoundException if the path does not exist.  Some throws 
 IOException only (FTPFileSystem, HftpFileSystem ...). 
 If we have a new FileSystem implementation, what should we follow exactly for 
 open()?
 What should the application expect in this case.
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9597) FileSystem open() API is not clear if FileNotFoundException is throw when the path does not exist

2013-05-24 Thread Suresh Srinivas (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666025#comment-13666025
 ] 

Suresh Srinivas commented on HADOOP-9597:
-

Jerry, please do not open jiras for asking questions. Jiras are for reporting 
problem.

FileSystem.java is not well documented and is implemented differently by 
different file systems. My recommendation would be to follow 
DistributedFileSystem implementation. You could also use FileContext javadoc to 
guide in what exception to throw.

 FileSystem open() API is not clear if FileNotFoundException is throw when the 
 path does not exist
 -

 Key: HADOOP-9597
 URL: https://issues.apache.org/jira/browse/HADOOP-9597
 Project: Hadoop Common
  Issue Type: Improvement
  Components: documentation, fs
Affects Versions: 2.0.4-alpha
Reporter: Jerry He
Priority: Minor
 Fix For: 2.0.4.1-alpha


 The current FileSystem open() method throws a generic IOException in its API 
 specification.
 Some FileSystem implementations (DFS, RawLocalFileSystem ...) throws more 
 specific FileNotFoundException if the path does not exist.  Some throws 
 IOException only (FTPFileSystem, HftpFileSystem ...). 
 If we have a new FileSystem implementation, what should we follow exactly for 
 open()?
 What should the application expect in this case.
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Comment Edited] (HADOOP-9435) Minimal code change to support IBM jvm build dependency

2013-05-24 Thread Suresh Srinivas (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13664943#comment-13664943
 ] 

Suresh Srinivas edited comment on HADOOP-9435 at 5/24/13 6:23 AM:
--

[~tianhonglouis] Want to make sure that this is ready to be committed and no 
tests are pending.

  was (Author: sureshms):
[~tianhonglouis] Want to make sure that this is ready to be committed and 
not tests are pending.
  
 Minimal code change to support IBM jvm build dependency
 ---

 Key: HADOOP-9435
 URL: https://issues.apache.org/jira/browse/HADOOP-9435
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Reporter: Tian Hong Wang
Assignee: Tian Hong Wang
  Labels: patch
 Attachments: HADOOP-9435.patch, HADOOP-9435-v1.patch


 When native build hadoop-common-project with IBM java using command like: 
 mvn package -Pnative
 it will exist the following errors.
  [exec] -- Configuring incomplete, errors occurred!
  [exec] JAVA_HOME=, 
 JAVA_JVM_LIBRARY=/home/louis/ibm-java-i386-60/jre/lib/i386/classic/libjvm.so
  [exec] JAVA_INCLUDE_PATH=/home/louis/ibm-java-i386-60/include, 
 JAVA_INCLUDE_PATH2=JAVA_INCLUDE_PATH2-NOTFOUND
  [exec] CMake Error at JNIFlags.cmake:113 (MESSAGE):
  [exec]   Failed to find a viable JVM installation under JAVA_HOME.
  [exec] Call Stack (most recent call first):
  [exec]   CMakeLists.txt:24 (include)
 The reason is that IBM java uses $JAVA_HOME/include/jniport.h instead of 
 $JAVA_HOME/include/jni_md.h in non-IBM java.
 [exec] 
 /usr/lib/jvm/java-1.6.0-ibm-1.6.0.12.0.x86_64/jre/lib/amd64/default/libjvm.so:
  undefined reference to `dlsym'
  [exec] 
 /usr/lib/jvm/java-1.6.0-ibm-1.6.0.12.0.x86_64/jre/lib/amd64/default/libjvm.so:
  undefined reference to `dlerror'
  [exec] 
 /usr/lib/jvm/java-1.6.0-ibm-1.6.0.12.0.x86_64/jre/lib/amd64/default/libjvm.so:
  undefined reference to `dladdr'
  [exec] 
 /usr/lib/jvm/java-1.6.0-ibm-1.6.0.12.0.x86_64/jre/lib/amd64/default/libjvm.so:
  undefined reference to `dlopen'
  [exec] 
 /usr/lib/jvm/java-1.6.0-ibm-1.6.0.12.0.x86_64/jre/lib/amd64/default/libjvm.so:
  undefined reference to `dlclose'
  [exec] collect2: ld returned 1 exit status
  [exec] make[2]: *** [test_libhdfs_ops] Error 1
  [exec] make[1]: *** [CMakeFiles/test_libhdfs_ops.dir/all] Error 2
  [exec] make: *** [all] Error 
 The reason is libjvm.so need libdl when linking.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (HADOOP-9598) test coverage for org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin

2013-05-24 Thread Aleksey Gorshkov (JIRA)
Aleksey Gorshkov created HADOOP-9598:


 Summary: test coverage for 
org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin
 Key: HADOOP-9598
 URL: https://issues.apache.org/jira/browse/HADOOP-9598
 Project: Hadoop Common
  Issue Type: Test
Affects Versions: 3.0.0, 0.23.8, 2.0.4.1-alpha
Reporter: Aleksey Gorshkov




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9598) test coverage for org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin

2013-05-24 Thread Aleksey Gorshkov (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Gorshkov updated HADOOP-9598:
-

Attachment: HADOOP-9598-trunk.patch
HADOOP-9598-branch-0.23.patch

 test coverage for 
 org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin
 -

 Key: HADOOP-9598
 URL: https://issues.apache.org/jira/browse/HADOOP-9598
 Project: Hadoop Common
  Issue Type: Test
Affects Versions: 3.0.0, 0.23.8, 2.0.4.1-alpha
Reporter: Aleksey Gorshkov
 Attachments: HADOOP-9598-branch-0.23.patch, HADOOP-9598-trunk.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9598) test coverage for org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin

2013-05-24 Thread Aleksey Gorshkov (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666104#comment-13666104
 ] 

Aleksey Gorshkov commented on HADOOP-9598:
--

patch HADOOP-9598-branch-0.23.patch for branch-0.23
patch HADOOP-9598-trunk.patch for branch-2 and trunk



 test coverage for 
 org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin
 -

 Key: HADOOP-9598
 URL: https://issues.apache.org/jira/browse/HADOOP-9598
 Project: Hadoop Common
  Issue Type: Test
Affects Versions: 3.0.0, 0.23.8, 2.0.4.1-alpha
Reporter: Aleksey Gorshkov
 Attachments: HADOOP-9598-branch-0.23.patch, HADOOP-9598-trunk.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9598) test coverage for org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin

2013-05-24 Thread Aleksey Gorshkov (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Gorshkov updated HADOOP-9598:
-

Status: Patch Available  (was: Open)

 test coverage for 
 org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin
 -

 Key: HADOOP-9598
 URL: https://issues.apache.org/jira/browse/HADOOP-9598
 Project: Hadoop Common
  Issue Type: Test
Affects Versions: 3.0.0, 0.23.8, 2.0.4.1-alpha
Reporter: Aleksey Gorshkov
 Attachments: HADOOP-9598-branch-0.23.patch, HADOOP-9598-trunk.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9598) test coverage for org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666117#comment-13666117
 ] 

Hadoop QA commented on HADOOP-9598:
---

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12584659/HADOOP-9598-trunk.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2564//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2564//console

This message is automatically generated.

 test coverage for 
 org.apache.hadoop.yarn.server.resourcemanager.tools.TestRMAdmin
 -

 Key: HADOOP-9598
 URL: https://issues.apache.org/jira/browse/HADOOP-9598
 Project: Hadoop Common
  Issue Type: Test
Affects Versions: 3.0.0, 0.23.8, 2.0.4.1-alpha
Reporter: Aleksey Gorshkov
 Attachments: HADOOP-9598-branch-0.23.patch, HADOOP-9598-trunk.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9063) enhance unit-test coverage of class org.apache.hadoop.fs.FileUtil

2013-05-24 Thread Dennis Y (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Y updated HADOOP-9063:
-

Attachment: HADOOP-9063-branch-2--N2.patch

resolved merge conflict in patch for branch-2

 enhance unit-test coverage of class org.apache.hadoop.fs.FileUtil
 -

 Key: HADOOP-9063
 URL: https://issues.apache.org/jira/browse/HADOOP-9063
 Project: Hadoop Common
  Issue Type: Test
Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.6
Reporter: Ivan A. Veselovsky
Assignee: Ivan A. Veselovsky
Priority: Minor
 Attachments: HADOOP-9063--b.patch, HADOOP-9063-branch-0.23--b.patch, 
 HADOOP-9063-branch-0.23--c.patch, HADOOP-9063-branch-2--N1.patch, 
 HADOOP-9063-branch-2--N2.patch, HADOOP-9063.patch, 
 HADOOP-9063-trunk--c.patch, HADOOP-9063-trunk--c.patch, 
 HADOOP-9063-trunk--N2.patch, HADOOP-9063-trunk--N3.patch, 
 HADOOP-9063-trunk--N6.patch


 Some methods of class org.apache.hadoop.fs.FileUtil are covered by unit-tests 
 poorly or not covered at all. Enhance the coverage.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9593) stack trace printed at ERROR for all yarn clients without hadoop.home set

2013-05-24 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666199#comment-13666199
 ] 

Hudson commented on HADOOP-9593:


Integrated in Hadoop-Yarn-trunk #219 (See 
[https://builds.apache.org/job/Hadoop-Yarn-trunk/219/])
HADOOP-9593 stack trace printed at ERROR for all yarn clients without 
hadoop.home set (Revision 1485842)

 Result = SUCCESS
stevel : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1485842
Files : 
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
* 
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/Shell.java


 stack trace printed at ERROR for all yarn clients without hadoop.home set
 -

 Key: HADOOP-9593
 URL: https://issues.apache.org/jira/browse/HADOOP-9593
 Project: Hadoop Common
  Issue Type: Bug
  Components: util
Affects Versions: 3.0.0
Reporter: Steve Loughran
 Attachments: HADOOP-9593-001.patch, HADOOP-9593-002.patch


 This is the problem of HADOOP-9482 now showing up in a different application 
 -one whose log4j settings haven't turned off all Shell logging.
 Unless you do that, all yarn clients will have a stack trace at error in 
 their logs, which is generating false alarms and is utterly pointless. Why 
 does this merit a stack trace? Why log it at error? It's not an error for a 
 client app to not have these values set as long as they have the relevant 
 JARs on their classpath. And if they don't, they'll get some classpath error 
 instead

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9063) enhance unit-test coverage of class org.apache.hadoop.fs.FileUtil

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666214#comment-13666214
 ] 

Hadoop QA commented on HADOOP-9063:
---

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12584679/HADOOP-9063-branch-2--N2.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 1 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-common-project/hadoop-common.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2565//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2565//console

This message is automatically generated.

 enhance unit-test coverage of class org.apache.hadoop.fs.FileUtil
 -

 Key: HADOOP-9063
 URL: https://issues.apache.org/jira/browse/HADOOP-9063
 Project: Hadoop Common
  Issue Type: Test
Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.6
Reporter: Ivan A. Veselovsky
Assignee: Ivan A. Veselovsky
Priority: Minor
 Attachments: HADOOP-9063--b.patch, HADOOP-9063-branch-0.23--b.patch, 
 HADOOP-9063-branch-0.23--c.patch, HADOOP-9063-branch-2--N1.patch, 
 HADOOP-9063-branch-2--N2.patch, HADOOP-9063.patch, 
 HADOOP-9063-trunk--c.patch, HADOOP-9063-trunk--c.patch, 
 HADOOP-9063-trunk--N2.patch, HADOOP-9063-trunk--N3.patch, 
 HADOOP-9063-trunk--N6.patch


 Some methods of class org.apache.hadoop.fs.FileUtil are covered by unit-tests 
 poorly or not covered at all. Enhance the coverage.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9593) stack trace printed at ERROR for all yarn clients without hadoop.home set

2013-05-24 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666287#comment-13666287
 ] 

Hudson commented on HADOOP-9593:


Integrated in Hadoop-Hdfs-trunk #1409 (See 
[https://builds.apache.org/job/Hadoop-Hdfs-trunk/1409/])
HADOOP-9593 stack trace printed at ERROR for all yarn clients without 
hadoop.home set (Revision 1485842)

 Result = FAILURE
stevel : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1485842
Files : 
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
* 
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/Shell.java


 stack trace printed at ERROR for all yarn clients without hadoop.home set
 -

 Key: HADOOP-9593
 URL: https://issues.apache.org/jira/browse/HADOOP-9593
 Project: Hadoop Common
  Issue Type: Bug
  Components: util
Affects Versions: 3.0.0
Reporter: Steve Loughran
 Attachments: HADOOP-9593-001.patch, HADOOP-9593-002.patch


 This is the problem of HADOOP-9482 now showing up in a different application 
 -one whose log4j settings haven't turned off all Shell logging.
 Unless you do that, all yarn clients will have a stack trace at error in 
 their logs, which is generating false alarms and is utterly pointless. Why 
 does this merit a stack trace? Why log it at error? It's not an error for a 
 client app to not have these values set as long as they have the relevant 
 JARs on their classpath. And if they don't, they'll get some classpath error 
 instead

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9593) stack trace printed at ERROR for all yarn clients without hadoop.home set

2013-05-24 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666334#comment-13666334
 ] 

Hudson commented on HADOOP-9593:


Integrated in Hadoop-Mapreduce-trunk #1435 (See 
[https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1435/])
HADOOP-9593 stack trace printed at ERROR for all yarn clients without 
hadoop.home set (Revision 1485842)

 Result = SUCCESS
stevel : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1485842
Files : 
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
* 
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/Shell.java


 stack trace printed at ERROR for all yarn clients without hadoop.home set
 -

 Key: HADOOP-9593
 URL: https://issues.apache.org/jira/browse/HADOOP-9593
 Project: Hadoop Common
  Issue Type: Bug
  Components: util
Affects Versions: 3.0.0
Reporter: Steve Loughran
 Attachments: HADOOP-9593-001.patch, HADOOP-9593-002.patch


 This is the problem of HADOOP-9482 now showing up in a different application 
 -one whose log4j settings haven't turned off all Shell logging.
 Unless you do that, all yarn clients will have a stack trace at error in 
 their logs, which is generating false alarms and is utterly pointless. Why 
 does this merit a stack trace? Why log it at error? It's not an error for a 
 client app to not have these values set as long as they have the relevant 
 JARs on their classpath. And if they don't, they'll get some classpath error 
 instead

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9573) Fix test-patch script to work with the enhanced PreCommit-Admin script.

2013-05-24 Thread Matt Foley (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666428#comment-13666428
 ] 

Matt Foley commented on HADOOP-9573:


+1, Thanks, Giri!


 Fix test-patch script to work with the enhanced PreCommit-Admin script.
 ---

 Key: HADOOP-9573
 URL: https://issues.apache.org/jira/browse/HADOOP-9573
 Project: Hadoop Common
  Issue Type: Sub-task
  Components: build
Affects Versions: 1.0.3
Reporter: Giridharan Kesavan
Assignee: Giridharan Kesavan
 Attachments: 
 0001-Fix-test-patch-scrit-to-work-with-the-enhanced-PreCo.patch, 
 hadoop-9573.patch


 test-patch script currently take the latest available patch for a given jira 
 and performs the test. This jira is to enhance test-patch script to take 
 attachment-id of a patch as an input and perform the tests using that 
 attachment-id

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-8468) Umbrella of enhancements to support different failure and locality topologies

2013-05-24 Thread Junping Du (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666454#comment-13666454
 ] 

Junping Du commented on HADOOP-8468:


I start the work to backport NodeGroup-aware topology to branch-2, there are 7 
patches below in Common  HDFS:
patch 1 - HADOOP-8469: make NetworkTopology pluggable
patch 2 - HADOOP-8470: implementation of NetworkTopologyWithNodeGroup
patch 3 - HDFS-3498: Make BlockPlacementPolicyWithDefault extensible and Block 
Placement Removal policy extensible
patch 4 - HDFS-3601: implementation of BlockPlacementPolicyWithNodeGroup
patch 5 - HDFS-4240: fix a bug in nodegroup-aware case
patch 6 - HDFS-3495: Make Balancer support node group layer
patch 7 - HDFS-4261: Fix a timeout issue in TestBalancerWithNodeGroup case


 Umbrella of enhancements to support different failure and locality topologies
 -

 Key: HADOOP-8468
 URL: https://issues.apache.org/jira/browse/HADOOP-8468
 Project: Hadoop Common
  Issue Type: Improvement
  Components: ha, io
Affects Versions: 1.0.0, 2.0.0-alpha
Reporter: Junping Du
Assignee: Junping Du
 Attachments: HADOOP-8468-total.patch, HADOOP-8468-total-v3.patch, 
 HVE_Hadoop World Meetup 2012.pptx, HVE User Guide on branch-1(draft ).pdf, 
 Proposal for enchanced failure and locality topologies.pdf, Proposal for 
 enchanced failure and locality topologies (revised-1.0).pdf


 The current hadoop network topology (described in some previous issues like: 
 Hadoop-692) works well in classic three-tiers network when it comes out. 
 However, it does not take into account other failure models or changes in the 
 infrastructure that can affect network bandwidth efficiency like: 
 virtualization. 
 Virtualized platform has following genes that shouldn't been ignored by 
 hadoop topology in scheduling tasks, placing replica, do balancing or 
 fetching block for reading: 
 1. VMs on the same physical host are affected by the same hardware failure. 
 In order to match the reliability of a physical deployment, replication of 
 data across two virtual machines on the same host should be avoided.
 2. The network between VMs on the same physical host has higher throughput 
 and lower latency and does not consume any physical switch bandwidth.
 Thus, we propose to make hadoop network topology extend-able and introduce a 
 new level in the hierarchical topology, a node group level, which maps well 
 onto an infrastructure that is based on a virtualized environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9597) FileSystem open() API is not clear if FileNotFoundException is throw when the path does not exist

2013-05-24 Thread Jerry He (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666493#comment-13666493
 ] 

Jerry He commented on HADOOP-9597:
--

Hi, Suresh

Thanks for you comment.

But isn't this a problem? FileSystem interface is such an important interface.

We have a proprietary implementation of FileSystem that does not throws 
FileNotFoundException.
It causes a problem for HBase, which expects FileNotFoundException in one 
particular case.
There could be other implementations out there.

Java FileInputStream specifically throws FileNotFoundException, which is 
commonly used.

We need to be clear, of course unless we intend to be ambiguous in this case.

 FileSystem open() API is not clear if FileNotFoundException is throw when the 
 path does not exist
 -

 Key: HADOOP-9597
 URL: https://issues.apache.org/jira/browse/HADOOP-9597
 Project: Hadoop Common
  Issue Type: Improvement
  Components: documentation, fs
Affects Versions: 2.0.4-alpha
Reporter: Jerry He
Priority: Minor
 Fix For: 2.0.4.1-alpha


 The current FileSystem open() method throws a generic IOException in its API 
 specification.
 Some FileSystem implementations (DFS, RawLocalFileSystem ...) throws more 
 specific FileNotFoundException if the path does not exist.  Some throws 
 IOException only (FTPFileSystem, HftpFileSystem ...). 
 If we have a new FileSystem implementation, what should we follow exactly for 
 open()?
 What should the application expect in this case.
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (HADOOP-9599) hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly

2013-05-24 Thread Mostafa Elhemali (JIRA)
Mostafa Elhemali created HADOOP-9599:


 Summary: hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly
 Key: HADOOP-9599
 URL: https://issues.apache.org/jira/browse/HADOOP-9599
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali


In Windows, hadoop-config.cmd uses the non-existent-variable HADOOP_CORE_HOME 
when setting the JAVA_LIBRAR_PATH variable. It should use HADOOP_HOME.
The net effect is that running e.g. hdfs namenode would error out with 
UnsatisfiedLinkError because it can't access hadoop.dll.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9599) hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly

2013-05-24 Thread Mostafa Elhemali (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mostafa Elhemali updated HADOOP-9599:
-

Attachment: HADOOP-9599.patch

 hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly
 -

 Key: HADOOP-9599
 URL: https://issues.apache.org/jira/browse/HADOOP-9599
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9599.patch


 In Windows, hadoop-config.cmd uses the non-existent-variable HADOOP_CORE_HOME 
 when setting the JAVA_LIBRAR_PATH variable. It should use HADOOP_HOME.
 The net effect is that running e.g. hdfs namenode would error out with 
 UnsatisfiedLinkError because it can't access hadoop.dll.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9599) hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly

2013-05-24 Thread Mostafa Elhemali (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mostafa Elhemali updated HADOOP-9599:
-

Status: Patch Available  (was: Open)

 hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly
 -

 Key: HADOOP-9599
 URL: https://issues.apache.org/jira/browse/HADOOP-9599
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9599.patch


 In Windows, hadoop-config.cmd uses the non-existent-variable HADOOP_CORE_HOME 
 when setting the JAVA_LIBRAR_PATH variable. It should use HADOOP_HOME.
 The net effect is that running e.g. hdfs namenode would error out with 
 UnsatisfiedLinkError because it can't access hadoop.dll.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Mostafa Elhemali (JIRA)
Mostafa Elhemali created HADOOP-9600:


 Summary: In Windows: Hadoop fails to run when JAVA_HOME has spaces 
in it
 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali


hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Mostafa Elhemali (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mostafa Elhemali updated HADOOP-9600:
-

Attachment: HADOOP-9600.patch

 In Windows: Hadoop fails to run when JAVA_HOME has spaces in it
 ---

 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9600.patch


 hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
 in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Mostafa Elhemali (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mostafa Elhemali updated HADOOP-9600:
-

Status: Patch Available  (was: Open)

 In Windows: Hadoop fails to run when JAVA_HOME has spaces in it
 ---

 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9600.patch


 hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
 in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9290) Some tests cannot load native library

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9290:


Fix Version/s: 3.0.0

 Some tests cannot load native library
 -

 Key: HADOOP-9290
 URL: https://issues.apache.org/jira/browse/HADOOP-9290
 Project: Hadoop Common
  Issue Type: Bug
  Components: build, native
Affects Versions: 3.0.0
Reporter: Arpit Agarwal
Assignee: Chris Nauroth
 Fix For: 3.0.0

 Attachments: HADOOP-9290.2.patch, HADOOP-9290.3.patch, 
 HADOOP-9290.4.patch, HADOOP-9290.patch


 Some tests are unable to load the native DLL on Windows. The culprit appears 
 to be an incorrect PATH configuration for the native-win profile in 
 hadoop-project/pom.xml.
 {code:xml}
 profile
   idnative-win/id
   activation
 os
   familyWindows/family
 /os
   /activation
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-surefire-plugin/artifactId
 configuration
   environmentVariables
 !-- Specify where to look for the native DLL on Windows --
 
 PATH${env.PATH};${basedir}\..\..\hadoop-common-project\hadoop-common\target\bin;/PATH
   /environmentVariables
 /configuration
   /plugin
 /plugins
   /build
 /profile
 {code}
 This is evaluated independently by each project and the relative path is not 
 always correct.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666552#comment-13666552
 ] 

Hadoop QA commented on HADOOP-9600:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12584733/HADOOP-9600.patch
  against trunk revision .

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2566//console

This message is automatically generated.

 In Windows: Hadoop fails to run when JAVA_HOME has spaces in it
 ---

 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9600.patch


 hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
 in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9599) hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666554#comment-13666554
 ] 

Hadoop QA commented on HADOOP-9599:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12584729/HADOOP-9599.patch
  against trunk revision .

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2567//console

This message is automatically generated.

 hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly
 -

 Key: HADOOP-9599
 URL: https://issues.apache.org/jira/browse/HADOOP-9599
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9599.patch


 In Windows, hadoop-config.cmd uses the non-existent-variable HADOOP_CORE_HOME 
 when setting the JAVA_LIBRAR_PATH variable. It should use HADOOP_HOME.
 The net effect is that running e.g. hdfs namenode would error out with 
 UnsatisfiedLinkError because it can't access hadoop.dll.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Mostafa Elhemali (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mostafa Elhemali updated HADOOP-9600:
-

Attachment: HADOOP-9600.2.patch

 In Windows: Hadoop fails to run when JAVA_HOME has spaces in it
 ---

 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9600.2.patch, HADOOP-9600.patch


 hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
 in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666572#comment-13666572
 ] 

Hadoop QA commented on HADOOP-9600:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12584736/HADOOP-9600.2.patch
  against trunk revision .

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2568//console

This message is automatically generated.

 In Windows: Hadoop fails to run when JAVA_HOME has spaces in it
 ---

 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9600.2.patch, HADOOP-9600.patch


 hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
 in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9287) Parallel testing hadoop-common

2013-05-24 Thread Andrey Klochkov (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666592#comment-13666592
 ] 

Andrey Klochkov commented on HADOOP-9287:
-

 Definitely separate the yarn changes, create a new ticket at 
 https://issues.apache.org/jira/browse/YARN. Tx.

All changes in YARN code introduced in this patch are required because YARN 
test classes depend on classes from hadoop-common. If we extract these changes 
somewhere else, this patch would lead to a non-compilable code. 

 Parallel testing hadoop-common
 --

 Key: HADOOP-9287
 URL: https://issues.apache.org/jira/browse/HADOOP-9287
 Project: Hadoop Common
  Issue Type: Test
  Components: test
Affects Versions: 3.0.0
Reporter: Tsuyoshi OZAWA
Assignee: Andrey Klochkov
 Attachments: HADOOP-9287.1.patch, HADOOP-9287--N3.patch, 
 HADOOP-9287--N3.patch, HADOOP-9287--N4.patch, HADOOP-9287--N5.patch, 
 HADOOP-9287.patch, HADOOP-9287.patch


 The maven surefire plugin supports parallel testing feature. By using it, the 
 tests can be run more faster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9407) commons-daemon 1.0.3 dependency has bad group id causing build issues

2013-05-24 Thread Konstantin Boudnik (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Boudnik updated HADOOP-9407:
---

Fix Version/s: 2.0.4.1-alpha

 commons-daemon 1.0.3 dependency has bad group id causing build issues
 -

 Key: HADOOP-9407
 URL: https://issues.apache.org/jira/browse/HADOOP-9407
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Affects Versions: 2.0.3-alpha, 2.0.4-alpha
Reporter: Sangjin Lee
Assignee: Sangjin Lee
  Labels: 2.0.4
 Fix For: 2.0.5-beta, 2.0.4.1-alpha

 Attachments: HDFS-4497.patch


 The commons-daemon dependency of the hadoop-hdfs module has been at version 
 1.0.3 for a while. However, 1.0.3 has a pretty well-known groupId error in 
 its pom (org.apache.commons as opposed to commons-daemon). This problem 
 has since been corrected on commons-daemon starting 1.0.4.
 This causes build problems for many who depend on hadoop-hdfs directly and 
 indirectly, however. Maven can skip over this metadata inconsistency. But 
 other less forgiving build systems such as ivy and gradle have much harder 
 time working around this problem. For example, in gradle, pretty much the 
 only obvious way to work around this is to override this dependency version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9593) stack trace printed at ERROR for all yarn clients without hadoop.home set

2013-05-24 Thread Steve Loughran (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Loughran updated HADOOP-9593:
---

   Resolution: Fixed
Fix Version/s: 2.0.5-beta
   3.0.0
 Assignee: Steve Loughran
   Status: Resolved  (was: Patch Available)

 stack trace printed at ERROR for all yarn clients without hadoop.home set
 -

 Key: HADOOP-9593
 URL: https://issues.apache.org/jira/browse/HADOOP-9593
 Project: Hadoop Common
  Issue Type: Bug
  Components: util
Affects Versions: 3.0.0
Reporter: Steve Loughran
Assignee: Steve Loughran
 Fix For: 3.0.0, 2.0.5-beta

 Attachments: HADOOP-9593-001.patch, HADOOP-9593-002.patch


 This is the problem of HADOOP-9482 now showing up in a different application 
 -one whose log4j settings haven't turned off all Shell logging.
 Unless you do that, all yarn clients will have a stack trace at error in 
 their logs, which is generating false alarms and is utterly pointless. Why 
 does this merit a stack trace? Why log it at error? It's not an error for a 
 client app to not have these values set as long as they have the relevant 
 JARs on their classpath. And if they don't, they'll get some classpath error 
 instead

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9582) Non-existent file to hadoop fs -conf doesn't throw error

2013-05-24 Thread Ashwin Shankar (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashwin Shankar updated HADOOP-9582:
---

Attachment: HADOOP-9582.txt

I've turned on the 'quiet' flag in FsShell.
This would cause a Runtime exception to be raised when the user gives a 
nonexistent resource. I've also changed INFO logs(which depends on the flag) to 
debug so that output is not verbose.

 Non-existent file to hadoop fs -conf doesn't throw error
 --

 Key: HADOOP-9582
 URL: https://issues.apache.org/jira/browse/HADOOP-9582
 Project: Hadoop Common
  Issue Type: Bug
  Components: conf
Affects Versions: 3.0.0, 0.23.7, 2.0.4-alpha
Reporter: Ashwin Shankar
 Attachments: HADOOP-9582.txt, HADOOP-9582.txt, HADOOP-9582.txt


 When we run :
 hadoop fs -conf BAD_FILE -ls /
 we expect hadoop to throw an error,but it doesn't.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9407) commons-daemon 1.0.3 dependency has bad group id causing build issues

2013-05-24 Thread Konstantin Boudnik (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1320#comment-1320
 ] 

Konstantin Boudnik commented on HADOOP-9407:


I have just committed this fix to 2.0.4.1-alpha release (branch-2.0.4-alpha). 
Thank you Sangjin.

 commons-daemon 1.0.3 dependency has bad group id causing build issues
 -

 Key: HADOOP-9407
 URL: https://issues.apache.org/jira/browse/HADOOP-9407
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Affects Versions: 2.0.3-alpha, 2.0.4-alpha
Reporter: Sangjin Lee
Assignee: Sangjin Lee
  Labels: 2.0.4
 Fix For: 2.0.5-beta, 2.0.4.1-alpha

 Attachments: HDFS-4497.patch


 The commons-daemon dependency of the hadoop-hdfs module has been at version 
 1.0.3 for a while. However, 1.0.3 has a pretty well-known groupId error in 
 its pom (org.apache.commons as opposed to commons-daemon). This problem 
 has since been corrected on commons-daemon starting 1.0.4.
 This causes build problems for many who depend on hadoop-hdfs directly and 
 indirectly, however. Maven can skip over this metadata inconsistency. But 
 other less forgiving build systems such as ivy and gradle have much harder 
 time working around this problem. For example, in gradle, pretty much the 
 only obvious way to work around this is to override this dependency version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9287) Parallel testing hadoop-common

2013-05-24 Thread Jason Lowe (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1323#comment-1323
 ] 

Jason Lowe commented on HADOOP-9287:


bq. All changes in YARN code introduced in this patch are required because YARN 
test classes depend on classes from hadoop-common. If we extract these changes 
somewhere else, this patch would lead to a non-compilable code. 

That doesn't seem to be the case.  I extracted the changes under 
hadoop-yarn-project into a separate patch, applied just that patch to trunk, 
and trunk built just fine.

Even if that were the case, it's better to track the changes for YARN under a 
separate JIRA that is dependent upon this one being integrated.  The only 
reason we aren't doing the same for HDFS is that those changes are intertwined. 
 We can't commit just the common changes without breaking the HDFS build and 
vice-versa.  That is not the case with the YARN changes, as the patch builds 
just fine without them.  Since they are independent changes, they should be 
tracked in their respective projects.

 Parallel testing hadoop-common
 --

 Key: HADOOP-9287
 URL: https://issues.apache.org/jira/browse/HADOOP-9287
 Project: Hadoop Common
  Issue Type: Test
  Components: test
Affects Versions: 3.0.0
Reporter: Tsuyoshi OZAWA
Assignee: Andrey Klochkov
 Attachments: HADOOP-9287.1.patch, HADOOP-9287--N3.patch, 
 HADOOP-9287--N3.patch, HADOOP-9287--N4.patch, HADOOP-9287--N5.patch, 
 HADOOP-9287.patch, HADOOP-9287.patch


 The maven surefire plugin supports parallel testing feature. By using it, the 
 tests can be run more faster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Reopened] (HADOOP-9597) FileSystem open() API is not clear if FileNotFoundException is throw when the path does not exist

2013-05-24 Thread Steve Loughran (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Loughran reopened HADOOP-9597:



 FileSystem open() API is not clear if FileNotFoundException is throw when the 
 path does not exist
 -

 Key: HADOOP-9597
 URL: https://issues.apache.org/jira/browse/HADOOP-9597
 Project: Hadoop Common
  Issue Type: Improvement
  Components: documentation, fs
Affects Versions: 2.0.4-alpha
Reporter: Jerry He
Priority: Minor
 Fix For: 2.0.4.1-alpha


 The current FileSystem open() method throws a generic IOException in its API 
 specification.
 Some FileSystem implementations (DFS, RawLocalFileSystem ...) throws more 
 specific FileNotFoundException if the path does not exist.  Some throws 
 IOException only (FTPFileSystem, HftpFileSystem ...). 
 If we have a new FileSystem implementation, what should we follow exactly for 
 open()?
 What should the application expect in this case.
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9597) FileSystem open() API is not clear if FileNotFoundException is throw when the path does not exist

2013-05-24 Thread Steve Loughran (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Loughran updated HADOOP-9597:
---

Issue Type: Sub-task  (was: Improvement)
Parent: HADOOP-9361

 FileSystem open() API is not clear if FileNotFoundException is throw when the 
 path does not exist
 -

 Key: HADOOP-9597
 URL: https://issues.apache.org/jira/browse/HADOOP-9597
 Project: Hadoop Common
  Issue Type: Sub-task
  Components: documentation, fs
Affects Versions: 2.0.4-alpha
Reporter: Jerry He
Priority: Minor
 Fix For: 2.0.4.1-alpha


 The current FileSystem open() method throws a generic IOException in its API 
 specification.
 Some FileSystem implementations (DFS, RawLocalFileSystem ...) throws more 
 specific FileNotFoundException if the path does not exist.  Some throws 
 IOException only (FTPFileSystem, HftpFileSystem ...). 
 If we have a new FileSystem implementation, what should we follow exactly for 
 open()?
 What should the application expect in this case.
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9407) commons-daemon 1.0.3 dependency has bad group id causing build issues

2013-05-24 Thread Sangjin Lee (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1334#comment-1334
 ] 

Sangjin Lee commented on HADOOP-9407:
-

Thanks Konstantin!

 commons-daemon 1.0.3 dependency has bad group id causing build issues
 -

 Key: HADOOP-9407
 URL: https://issues.apache.org/jira/browse/HADOOP-9407
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Affects Versions: 2.0.3-alpha, 2.0.4-alpha
Reporter: Sangjin Lee
Assignee: Sangjin Lee
  Labels: 2.0.4
 Fix For: 2.0.5-beta, 2.0.4.1-alpha

 Attachments: HDFS-4497.patch


 The commons-daemon dependency of the hadoop-hdfs module has been at version 
 1.0.3 for a while. However, 1.0.3 has a pretty well-known groupId error in 
 its pom (org.apache.commons as opposed to commons-daemon). This problem 
 has since been corrected on commons-daemon starting 1.0.4.
 This causes build problems for many who depend on hadoop-hdfs directly and 
 indirectly, however. Maven can skip over this metadata inconsistency. But 
 other less forgiving build systems such as ivy and gradle have much harder 
 time working around this problem. For example, in gradle, pretty much the 
 only obvious way to work around this is to override this dependency version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9407) commons-daemon 1.0.3 dependency has bad group id causing build issues

2013-05-24 Thread Konstantin Boudnik (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1337#comment-1337
 ] 

Konstantin Boudnik commented on HADOOP-9407:


I see this already committed to the branch-2, which is in my understanding is 
effectively tracking 2.0.5 release now. So, I guess the ticket should be closed.

 commons-daemon 1.0.3 dependency has bad group id causing build issues
 -

 Key: HADOOP-9407
 URL: https://issues.apache.org/jira/browse/HADOOP-9407
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Affects Versions: 2.0.3-alpha, 2.0.4-alpha
Reporter: Sangjin Lee
Assignee: Sangjin Lee
  Labels: 2.0.4
 Fix For: 2.0.5-beta, 2.0.4.1-alpha

 Attachments: HDFS-4497.patch


 The commons-daemon dependency of the hadoop-hdfs module has been at version 
 1.0.3 for a while. However, 1.0.3 has a pretty well-known groupId error in 
 its pom (org.apache.commons as opposed to commons-daemon). This problem 
 has since been corrected on commons-daemon starting 1.0.4.
 This causes build problems for many who depend on hadoop-hdfs directly and 
 indirectly, however. Maven can skip over this metadata inconsistency. But 
 other less forgiving build systems such as ivy and gradle have much harder 
 time working around this problem. For example, in gradle, pretty much the 
 only obvious way to work around this is to override this dependency version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9582) Non-existent file to hadoop fs -conf doesn't throw error

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1341#comment-1341
 ] 

Hadoop QA commented on HADOOP-9582:
---

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12584745/HADOOP-9582.txt
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 2 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-common-project/hadoop-common.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2569//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2569//console

This message is automatically generated.

 Non-existent file to hadoop fs -conf doesn't throw error
 --

 Key: HADOOP-9582
 URL: https://issues.apache.org/jira/browse/HADOOP-9582
 Project: Hadoop Common
  Issue Type: Bug
  Components: conf
Affects Versions: 3.0.0, 0.23.7, 2.0.4-alpha
Reporter: Ashwin Shankar
 Attachments: HADOOP-9582.txt, HADOOP-9582.txt, HADOOP-9582.txt


 When we run :
 hadoop fs -conf BAD_FILE -ls /
 we expect hadoop to throw an error,but it doesn't.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Mostafa Elhemali (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mostafa Elhemali updated HADOOP-9600:
-

Attachment: HADOOP-9600.3.patch

JAVA_HOME is also used within the code in Yarn application definitions - fixed 
what I could find there to quote it as well.

 In Windows: Hadoop fails to run when JAVA_HOME has spaces in it
 ---

 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9600.2.patch, HADOOP-9600.3.patch, 
 HADOOP-9600.patch


 hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
 in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9287) Parallel testing hadoop-common

2013-05-24 Thread Andrey Klochkov (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1367#comment-1367
 ] 

Andrey Klochkov commented on HADOOP-9287:
-

Indeed, I was wrong and the changes in YARN are not necessary in this patch. 
Seems these changes are not needed at all as yarn tests are not supposed to be 
run in parallel. Eliminating these from the patch. Thanks Jason!

 Parallel testing hadoop-common
 --

 Key: HADOOP-9287
 URL: https://issues.apache.org/jira/browse/HADOOP-9287
 Project: Hadoop Common
  Issue Type: Test
  Components: test
Affects Versions: 3.0.0
Reporter: Tsuyoshi OZAWA
Assignee: Andrey Klochkov
 Attachments: HADOOP-9287.1.patch, HADOOP-9287--N3.patch, 
 HADOOP-9287--N3.patch, HADOOP-9287--N4.patch, HADOOP-9287--N5.patch, 
 HADOOP-9287.patch, HADOOP-9287.patch


 The maven surefire plugin supports parallel testing feature. By using it, the 
 tests can be run more faster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9287) Parallel testing hadoop-common

2013-05-24 Thread Andrey Klochkov (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Klochkov updated HADOOP-9287:


Attachment: HADOOP-9287--N6.patch

 Parallel testing hadoop-common
 --

 Key: HADOOP-9287
 URL: https://issues.apache.org/jira/browse/HADOOP-9287
 Project: Hadoop Common
  Issue Type: Test
  Components: test
Affects Versions: 3.0.0
Reporter: Tsuyoshi OZAWA
Assignee: Andrey Klochkov
 Attachments: HADOOP-9287.1.patch, HADOOP-9287--N3.patch, 
 HADOOP-9287--N3.patch, HADOOP-9287--N4.patch, HADOOP-9287--N5.patch, 
 HADOOP-9287--N6.patch, HADOOP-9287.patch, HADOOP-9287.patch


 The maven surefire plugin supports parallel testing feature. By using it, the 
 tests can be run more faster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9579) Contrib ant test target not setting the java.library.path

2013-05-24 Thread Chuan Liu (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666724#comment-13666724
 ] 

Chuan Liu commented on HADOOP-9579:
---

+1

Do we know which tests will behave differently with or without native library?

 Contrib ant test target not setting the java.library.path
 -

 Key: HADOOP-9579
 URL: https://issues.apache.org/jira/browse/HADOOP-9579
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 1-win
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Attachments: HADOOP-9579.branch-1-win.patch


 build-contrib.xml does not set java.library.path causing tests to run without 
 the hadoop native library. This is a bigger problem on Windows as having the 
 native library is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666730#comment-13666730
 ] 

Hadoop QA commented on HADOOP-9600:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12584754/HADOOP-9600.3.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-common-project/hadoop-common 
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app 
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient
 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2570//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2570//console

This message is automatically generated.

 In Windows: Hadoop fails to run when JAVA_HOME has spaces in it
 ---

 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9600.2.patch, HADOOP-9600.3.patch, 
 HADOOP-9600.patch


 hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
 in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9421) Convert SASL to use ProtoBuf and add lengths for non-blocking processing

2013-05-24 Thread Daryn Sharp (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666735#comment-13666735
 ] 

Daryn Sharp commented on HADOOP-9421:
-

Out-of-sync issues are inevitable if the client or server goes into a specific 
mode where it assumes a specific protobuf.  Ie. How does a secure client know 
if it will get a RPC failure or SASL response after it sends the connection 
header?  How can you fix the bad version response to handle that?

Simply wrapping the sasl protobufs like other rpc calls allows the 
client/server to know how to decode the subsequent protbuf message.  I don't 
feel it's a hack so much as good design.  If this is our foreseeable last 
chance to modify RPC, then we need to make rpc decoding as flexible as possible.

 Convert SASL to use ProtoBuf and add lengths for non-blocking processing
 

 Key: HADOOP-9421
 URL: https://issues.apache.org/jira/browse/HADOOP-9421
 Project: Hadoop Common
  Issue Type: Sub-task
Affects Versions: 2.0.3-alpha
Reporter: Sanjay Radia
Assignee: Daryn Sharp
 Attachments: HADOOP-9421.patch, HADOOP-9421-v2-demo.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9373) Merge CHANGES.branch-trunk-win.txt to CHANGES.txt

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9373:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

Merged change to branch-2

 Merge CHANGES.branch-trunk-win.txt to CHANGES.txt
 -

 Key: HADOOP-9373
 URL: https://issues.apache.org/jira/browse/HADOOP-9373
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Suresh Srinivas
Assignee: Suresh Srinivas
Priority: Minor
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9373.patch, HADOOP-9373.patch


 This is to merge the changes from CHANGES.branch-trunk-win.txt to appropriate 
 CHANGES.txt files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9376) TestProxyUserFromEnv fails on a Windows domain joined machine

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9376:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

Merged changed to branch-2

 TestProxyUserFromEnv fails on a Windows domain joined machine
 -

 Key: HADOOP-9376
 URL: https://issues.apache.org/jira/browse/HADOOP-9376
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9376.trunk.patch


 TestProxyUserFromEnv#testProxyUserFromEnvironment fails with the following 
 error on my machine:
 org.junit.ComparisonFailure: expected:[redmond\]ivanmi but was:[]ivanmi
   at org.junit.Assert.assertEquals(Assert.java:123)
   at org.junit.Assert.assertEquals(Assert.java:145)
   at 
 org.apache.hadoop.security.TestProxyUserFromEnv.testProxyUserFromEnvironment(TestProxyUserFromEnv.java:45)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
   at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
   at 
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9365) TestHAZKUtil fails on Windows

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9365:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

Merged the change to branch-2

 TestHAZKUtil fails on Windows
 -

 Key: HADOOP-9365
 URL: https://issues.apache.org/jira/browse/HADOOP-9365
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0, trunk-win
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9365.branch-trunk-win.hazkutil.patch


 TestHAZKUtil#testConfIndirectionfails on the following validation:
 assertTrue(fnfe.getMessage().startsWith(BOGUS_FILE));
 because the path separators do not match:
 Expected: /-this-does-not-exist
 Actual: \-this-does-not-exist

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9364) PathData#expandAsGlob does not return correct results for absolute paths on Windows

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9364:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

Merged the change to branch-2

 PathData#expandAsGlob does not return correct results for absolute paths on 
 Windows
 ---

 Key: HADOOP-9364
 URL: https://issues.apache.org/jira/browse/HADOOP-9364
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0, trunk-win
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9364.2.patch, 
 HADOOP-9364.branch-trunk-win.pathdata.patch


 This causes {{FsShell ls}} not to work properly for absolute paths. For 
 example:
 {code}
 -fs hdfs://127.0.0.1:58559 -ls -R /dir0
 {code}
 returns
 {code}
 drwxr-xr-x   - ivanmi supergroup  0 2013-03-05 11:15 ../../dir0/dir1
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-8973) DiskChecker cannot reliably detect an inaccessible disk on Windows with NTFS ACLs

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-8973:


Target Version/s:   (was: 3.0.0, 1-win)
   Fix Version/s: (was: 3.0.0)
  2.0.5-beta

Merged the patch to branch-2

 DiskChecker cannot reliably detect an inaccessible disk on Windows with NTFS 
 ACLs
 -

 Key: HADOOP-8973
 URL: https://issues.apache.org/jira/browse/HADOOP-8973
 Project: Hadoop Common
  Issue Type: Bug
  Components: util
Affects Versions: 3.0.0, 1-win
Reporter: Chris Nauroth
Assignee: Chris Nauroth
 Fix For: 1-win, 2.0.5-beta

 Attachments: DiskChecker.proto.patch, HADOOP-8973.3.patch, 
 HADOOP-8973-branch-1-win.3.patch, HADOOP-8973-branch-trunk-win.2.patch, 
 HADOOP-8973-branch-trunk-win.patch


 DiskChecker.checkDir uses File.canRead, File.canWrite, and File.canExecute to 
 check if a directory is inaccessible.  These APIs are not reliable on Windows 
 with NTFS ACLs due to a known JVM bug.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9421) Convert SASL to use ProtoBuf and add lengths for non-blocking processing

2013-05-24 Thread Daryn Sharp (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daryn Sharp updated HADOOP-9421:


Attachment: HADOOP-9421.patch

I scaled back my patch to the simplest skeleton implementation.  The highlights 
are:
* SASL is very stateful
* SASL is wrapped with RPC header like normal requests to facility dynamic 
decoding
* Client can correctly handle RPC exceptions during SASL negotiation
* Server advertises SASL mechs to client

Deficiencies to be addressed in another jira:
* RPC client still pre-instantiates a SASL client and blindly uses it - instead 
of using the server advertisement
* RPC server is also pre-creating a SASL server
* Protocol and serverId not included in the SASL mech advertisement or the 
client initiate

Code cleanups:
* RPC client loop for SASL and normal operation should be folded together 
simplify and reduce redundant code
* RPC server decoding paths for connect/sasl/rpc can be greatly simplified - 
the existing impl is already a twisty maze

I've started on some of the cleanup, but I wanted to get a functional patch to 
unblock the start of v9 testing, and that I can use as a base for work of a 
larger scope.



 Convert SASL to use ProtoBuf and add lengths for non-blocking processing
 

 Key: HADOOP-9421
 URL: https://issues.apache.org/jira/browse/HADOOP-9421
 Project: Hadoop Common
  Issue Type: Sub-task
Affects Versions: 2.0.3-alpha
Reporter: Sanjay Radia
Assignee: Daryn Sharp
 Attachments: HADOOP-9421.patch, HADOOP-9421.patch, 
 HADOOP-9421-v2-demo.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9421) Convert SASL to use ProtoBuf and add lengths for non-blocking processing

2013-05-24 Thread Daryn Sharp (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daryn Sharp updated HADOOP-9421:


Status: Patch Available  (was: Open)

 Convert SASL to use ProtoBuf and add lengths for non-blocking processing
 

 Key: HADOOP-9421
 URL: https://issues.apache.org/jira/browse/HADOOP-9421
 Project: Hadoop Common
  Issue Type: Sub-task
Affects Versions: 2.0.3-alpha
Reporter: Sanjay Radia
Assignee: Daryn Sharp
 Attachments: HADOOP-9421.patch, HADOOP-9421.patch, 
 HADOOP-9421-v2-demo.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9388) TestFsShellCopy fails on Windows

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9388:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

Merged the patch to branch-2

 TestFsShellCopy fails on Windows
 

 Key: HADOOP-9388
 URL: https://issues.apache.org/jira/browse/HADOOP-9388
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9388.trunk.patch


 Test fails on below test cases:
 {code}
 Tests run: 11, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 4.343 sec 
  FAILURE!
 testMoveDirFromLocal(org.apache.hadoop.fs.TestFsShellCopy)  Time elapsed: 29 
 sec   FAILURE!
 java.lang.AssertionError: expected:0 but was:1
 at org.junit.Assert.fail(Assert.java:91)
 at org.junit.Assert.failNotEquals(Assert.java:645)
 at org.junit.Assert.assertEquals(Assert.java:126)
 at org.junit.Assert.assertEquals(Assert.java:470)
 at org.junit.Assert.assertEquals(Assert.java:454)
 at 
 org.apache.hadoop.fs.TestFsShellCopy.testMoveDirFromLocal(TestFsShellCopy.java:392)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
 at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
 at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
 at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
 at 
 org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
 at 
 org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
 at 
 org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
 at 
 org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
 at 
 org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
 at 
 org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
 at 
 org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
 testMoveDirFromLocalDestExists(org.apache.hadoop.fs.TestFsShellCopy)  Time 
 elapsed: 25 sec   FAILURE!
 java.lang.AssertionError: expected:0 but was:1
 at org.junit.Assert.fail(Assert.java:91)
 at org.junit.Assert.failNotEquals(Assert.java:645)
 at org.junit.Assert.assertEquals(Assert.java:126)
 at org.junit.Assert.assertEquals(Assert.java:470)
 at org.junit.Assert.assertEquals(Assert.java:454)
 at 
 org.apache.hadoop.fs.TestFsShellCopy.testMoveDirFromLocalDestExists(TestFsShellCopy.java:410)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at 

[jira] [Updated] (HADOOP-9437) TestNativeIO#testRenameTo fails on Windows due to assumption that POSIX errno is embedded in NativeIOException

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9437:


Target Version/s:   (was: 3.0.0)
   Fix Version/s: (was: 3.0.0)
  2.0.5-beta

I merged the patch to branch-2.

 TestNativeIO#testRenameTo fails on Windows due to assumption that POSIX errno 
 is embedded in NativeIOException
 --

 Key: HADOOP-9437
 URL: https://issues.apache.org/jira/browse/HADOOP-9437
 Project: Hadoop Common
  Issue Type: Bug
  Components: test
Affects Versions: 3.0.0
Reporter: Chris Nauroth
Assignee: Chris Nauroth
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9437.1.patch, HADOOP-9437.2.patch, 
 HADOOP-9437.3.patch


 HDFS-4428 added a detailed error message for failures to rename files by 
 embedding the POSIX errno in the {{NativeIOException}}.  On Windows, the 
 mapping of errno is not performed, so the errno enum value will not be 
 present in the {{NativeIOException}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9353) Activate native-win profile by default on Windows

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9353:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 Activate native-win profile by default on Windows
 -

 Key: HADOOP-9353
 URL: https://issues.apache.org/jira/browse/HADOOP-9353
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Affects Versions: 3.0.0
Reporter: Arpit Agarwal
Assignee: Arpit Agarwal
  Labels: windows
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9353.1.patch, HADOOP-9353.patch

   Original Estimate: 1m
  Remaining Estimate: 1m

 Hadoop on Windows requires native components to be available so the 
 native-win profile should be activated by default.
 The fix should update BUILDING.txt appropriately.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9486) Promote Windows and Shell related utils from YARN to Hadoop Common

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9486:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 Promote Windows and Shell related utils from YARN to Hadoop Common
 --

 Key: HADOOP-9486
 URL: https://issues.apache.org/jira/browse/HADOOP-9486
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Vinod Kumar Vavilapalli
Assignee: Chris Nauroth
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9486.patch


 This is happening as part of YARN-493, this is a tracking ticket for common 
 changes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9488) FileUtil#createJarWithClassPath only substitutes environment variables from current process environment/does not support overriding when launching new process

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9488:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 FileUtil#createJarWithClassPath only substitutes environment variables from 
 current process environment/does not support overriding when launching new 
 process
 --

 Key: HADOOP-9488
 URL: https://issues.apache.org/jira/browse/HADOOP-9488
 Project: Hadoop Common
  Issue Type: Bug
  Components: fs
Affects Versions: 3.0.0
Reporter: Chris Nauroth
Assignee: Chris Nauroth
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9488.1.patch, HADOOP-9488.consolidated.1.patch, 
 HADOOP-9488.consolidated.2.patch


 {{FileUtil#createJarWithClassPath}} always uses {{System#getEnv}} for 
 substitution of environment variables in the classpath bundled into the jar 
 manifest.  YARN launches container processes with a different set of 
 environment variables, so the method needs to support providing environment 
 variables different from the current process.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9490) LocalFileSystem#reportChecksumFailure not closing the checksum file handle before rename

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9490:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 LocalFileSystem#reportChecksumFailure not closing the checksum file handle 
 before rename
 

 Key: HADOOP-9490
 URL: https://issues.apache.org/jira/browse/HADOOP-9490
 Project: Hadoop Common
  Issue Type: Bug
  Components: fs
Affects Versions: 3.0.0
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9490.patch


 LocalFileSystem#reportChecksumFailure is not closing the open stream on the 
 checksum file before it moves it to the bad_files folder, what causes the 
 operation to fail on Windows.
 TestLocalFileSystem fail on Windows because of this:
 {code}
 testReportChecksumFailure(org.apache.hadoop.fs.TestLocalFileSystem)  Time 
 elapsed: 31 sec   FAILURE!
 java.lang.AssertionError: 
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.assertTrue(Assert.java:43)
   at org.junit.Assert.assertTrue(Assert.java:54)
   at 
 org.apache.hadoop.fs.TestLocalFileSystem.testReportChecksumFailure(TestLocalFileSystem.java:335)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9500) TestUserGroupInformation#testGetServerSideGroups fails on Windows due to failure to find winutils.exe

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9500:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 TestUserGroupInformation#testGetServerSideGroups fails on Windows due to 
 failure to find winutils.exe
 -

 Key: HADOOP-9500
 URL: https://issues.apache.org/jira/browse/HADOOP-9500
 Project: Hadoop Common
  Issue Type: Bug
  Components: test
Affects Versions: 3.0.0
Reporter: Chris Nauroth
Assignee: Chris Nauroth
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9500.1.patch


 The test attempts to run the winutils groups command, but the initialization 
 logic fails to find the path to winutils.exe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9290) Some tests cannot load native library

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9290:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 Some tests cannot load native library
 -

 Key: HADOOP-9290
 URL: https://issues.apache.org/jira/browse/HADOOP-9290
 Project: Hadoop Common
  Issue Type: Bug
  Components: build, native
Affects Versions: 3.0.0
Reporter: Arpit Agarwal
Assignee: Chris Nauroth
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9290.2.patch, HADOOP-9290.3.patch, 
 HADOOP-9290.4.patch, HADOOP-9290.patch


 Some tests are unable to load the native DLL on Windows. The culprit appears 
 to be an incorrect PATH configuration for the native-win profile in 
 hadoop-project/pom.xml.
 {code:xml}
 profile
   idnative-win/id
   activation
 os
   familyWindows/family
 /os
   /activation
   build
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-surefire-plugin/artifactId
 configuration
   environmentVariables
 !-- Specify where to look for the native DLL on Windows --
 
 PATH${env.PATH};${basedir}\..\..\hadoop-common-project\hadoop-common\target\bin;/PATH
   /environmentVariables
 /configuration
   /plugin
 /plugins
   /build
 /profile
 {code}
 This is evaluated independently by each project and the relative path is not 
 always correct.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9443) Port winutils static code analysis change to trunk

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9443:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 Port winutils static code analysis change to trunk
 --

 Key: HADOOP-9443
 URL: https://issues.apache.org/jira/browse/HADOOP-9443
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Chuan Liu
Assignee: Chuan Liu
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9443-trunk.patch


 We hit a problem in winutils when running tests on Windows. The static code 
 analysis change will fix the problem. More specifically, the old code always 
 assumes the security descriptor get from GetSecurityDescriptorControl() is 
 relative, and will make an absolute security descriptor out of it. The new 
 absolute security descriptor will then pass to SetSecurityDescriptorDacl() to 
 set permissions on the file. If the security descriptor is absolute, the new 
 absolute security descriptor will be NULL, and we will run into the problem. 
 This is what happened exactly in our case. The fix from static code analysis 
 will solve the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9553) TestAuthenticationToken fails on Windows

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9553:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 TestAuthenticationToken fails on Windows
 

 Key: HADOOP-9553
 URL: https://issues.apache.org/jira/browse/HADOOP-9553
 Project: Hadoop Common
  Issue Type: Bug
  Components: test
Affects Versions: 3.0.0
Reporter: Arpit Agarwal
Assignee: Arpit Agarwal
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9553.001.patch, HADOOP-9553.002.patch


 Likely test issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9556) disable HA tests on Windows that fail due to ZooKeeper client connection management bug

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9556:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 disable HA tests on Windows that fail due to ZooKeeper client connection 
 management bug
 ---

 Key: HADOOP-9556
 URL: https://issues.apache.org/jira/browse/HADOOP-9556
 Project: Hadoop Common
  Issue Type: Bug
  Components: ha, test
Affects Versions: 3.0.0
Reporter: Chris Nauroth
Assignee: Chris Nauroth
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9556.1.patch


 ZOOKEEPER-1702 tracks a client connection management bug that manifests 
 frequently on Windows.  Until a patch is available in a ZooKeeper release, we 
 need to disable the failing tests temporarily on Windows.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9483) winutils support for readlink command

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9483:


Target Version/s:   (was: 3.0.0)
   Fix Version/s: (was: 3.0.0)
  2.0.5-beta

I merged the patch to branch-2.

 winutils support for readlink command
 -

 Key: HADOOP-9483
 URL: https://issues.apache.org/jira/browse/HADOOP-9483
 Project: Hadoop Common
  Issue Type: Improvement
  Components: util
Affects Versions: 3.0.0
Reporter: Chris Nauroth
Assignee: Arpit Agarwal
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9483.003.patch, HADOOP-9483.004.patch, 
 HADOOP-9483.005.patch, HADOOP-9483.007.patch, HADOOP-9483.patch, 
 HADOOP-9483.patch


 The current codebase relies on the Unix readlink command to determine the 
 target of a symlink on the local file system.  winutils currently does not 
 support this functionality on Windows.  Adding the command to winutils will 
 prevent the need to use GnuWin32 or Cygwin for readlink support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9043) disallow in winutils creating symlinks with forwards slashes

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9043:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

I merged the patch to branch-2.

 disallow in winutils creating symlinks with forwards slashes
 

 Key: HADOOP-9043
 URL: https://issues.apache.org/jira/browse/HADOOP-9043
 Project: Hadoop Common
  Issue Type: Bug
  Components: util
Affects Versions: 3.0.0, 1-win
Reporter: Chris Nauroth
Assignee: Chris Nauroth
 Fix For: 1-win, 2.0.5-beta

 Attachments: HADOOP-9043.branch-1.2.patch, 
 HADOOP-9043.branch-1-win.5.patch, HADOOP-9043.branch-1-win.6.patch, 
 HADOOP-9043.branch-1-win.patch, HADOOP-9043.trunk.2.patch, 
 HADOOP-9043.trunk.3.patch, HADOOP-9043.trunk.4.patch, 
 HADOOP-9043.trunk.5.patch, HADOOP-9043.trunk.6.patch, HADOOP-9043.trunk.patch


 In general, the winutils symlink command rejects attempts to create symlinks 
 targeting a destination file that does not exist.  However, if given a 
 symlink destination with forward slashes pointing at a file that does exist, 
 then it creates the symlink with the forward slashes, and then attempts to 
 open the file through the symlink will fail.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9413) Introduce common utils for File#setReadable/Writable/Executable and File#canRead/Write/Execute that work cross-platform

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9413:


Target Version/s:   (was: 3.0.0)
   Fix Version/s: (was: 3.0.0)
  2.0.5-beta

I merged the patch to branch-2.

 Introduce common utils for File#setReadable/Writable/Executable and 
 File#canRead/Write/Execute that work cross-platform
 ---

 Key: HADOOP-9413
 URL: https://issues.apache.org/jira/browse/HADOOP-9413
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9413.commonfileutils.2.patch, 
 HADOOP-9413.commonfileutils.3.patch, HADOOP-9413.commonfileutils.4.patch, 
 HADOOP-9413.commonfileutils.5.patch, HADOOP-9413.commonfileutils.patch


 So far, we've seen many unittest and product bugs in Hadoop on Windows 
 because Java's APIs that manipulate with permissions do not work as expected. 
 We've addressed many of these problems on one-by-one basis (by either 
 changing code a bit or disabling the test). While debugging the remaining 
 unittest failures we continue to run into the same patterns of problems, and 
 instead of addressing them one-by-one, I propose that we expose a set of 
 equivalent wrapper APIs that will work well for all platforms.
 Scanning thru the codebase, this will actually be a simple change as there 
 are very few places that use File#setReadable/Writable/Executable and 
 File#canRead/Write/Execute (5 files in Common, 9 files in HDFS).
 HADOOP-8973 contains additional context on the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9524) Fix ShellCommandFencer to work on Windows

2013-05-24 Thread Suresh Srinivas (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Suresh Srinivas updated HADOOP-9524:


Fix Version/s: (was: 3.0.0)
   2.0.5-beta

 Fix ShellCommandFencer to work on Windows
 -

 Key: HADOOP-9524
 URL: https://issues.apache.org/jira/browse/HADOOP-9524
 Project: Hadoop Common
  Issue Type: Bug
  Components: ha
Affects Versions: 3.0.0
 Environment: Windows
Reporter: Arpit Agarwal
Assignee: Arpit Agarwal
  Labels: windows
 Fix For: 2.0.5-beta

 Attachments: HADOOP-9524.001.patch


 ShellcommandFencer has a hard-coded dependency on bash. Since we no longer 
 require cygwin/bash on Windows we must fix it to use cmd.exe instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9287) Parallel testing hadoop-common

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666818#comment-13666818
 ] 

Hadoop QA commented on HADOOP-9287:
---

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12584759/HADOOP-9287--N6.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 49 new 
or modified test files.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-common-project/hadoop-common hadoop-hdfs-project/hadoop-hdfs 
hadoop-tools/hadoop-distcp.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2571//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2571//console

This message is automatically generated.

 Parallel testing hadoop-common
 --

 Key: HADOOP-9287
 URL: https://issues.apache.org/jira/browse/HADOOP-9287
 Project: Hadoop Common
  Issue Type: Test
  Components: test
Affects Versions: 3.0.0
Reporter: Tsuyoshi OZAWA
Assignee: Andrey Klochkov
 Attachments: HADOOP-9287.1.patch, HADOOP-9287--N3.patch, 
 HADOOP-9287--N3.patch, HADOOP-9287--N4.patch, HADOOP-9287--N5.patch, 
 HADOOP-9287--N6.patch, HADOOP-9287.patch, HADOOP-9287.patch


 The maven surefire plugin supports parallel testing feature. By using it, the 
 tests can be run more faster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9421) Convert SASL to use ProtoBuf and add lengths for non-blocking processing

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666823#comment-13666823
 ] 

Hadoop QA commented on HADOOP-9421:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12584769/HADOOP-9421.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 core tests{color}.  The patch passed unit tests in 
hadoop-common-project/hadoop-common.

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2572//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2572//console

This message is automatically generated.

 Convert SASL to use ProtoBuf and add lengths for non-blocking processing
 

 Key: HADOOP-9421
 URL: https://issues.apache.org/jira/browse/HADOOP-9421
 Project: Hadoop Common
  Issue Type: Sub-task
Affects Versions: 2.0.3-alpha
Reporter: Sanjay Radia
Assignee: Daryn Sharp
 Attachments: HADOOP-9421.patch, HADOOP-9421.patch, 
 HADOOP-9421-v2-demo.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9371) Define Semantics of FileSystem and FileContext more rigorously

2013-05-24 Thread Konstantin Shvachko (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666838#comment-13666838
 ] 

Konstantin Shvachko commented on HADOOP-9371:
-

Steve, you might want to link the document from github to the jira. Add Link 
has an option to add a web link.

Not requiring atomicity for mkdirs() and recursive deletes makes sense to me.
For renames I think we should also restrict atomicity to one special case, when 
file or directory name changes, that is file is not moving from one directory 
to another. I call it in-place rename, which with inode numbers in place is a 
trivial operation. Atomic moves are hard if you build a distributed namespace 
service (like Giraffa). Moving a file between directories that are located on 
different nodes requires distributed coordination, which can be complex.

 Define Semantics of FileSystem and FileContext more rigorously
 --

 Key: HADOOP-9371
 URL: https://issues.apache.org/jira/browse/HADOOP-9371
 Project: Hadoop Common
  Issue Type: Sub-task
  Components: fs
Affects Versions: 1.2.0, 3.0.0
Reporter: Steve Loughran
Assignee: Steve Loughran
 Attachments: HADOOP-9361.2.patch, HADOOP-9361.patch, 
 HadoopFilesystemContract.pdf

   Original Estimate: 48h
  Remaining Estimate: 48h

 The semantics of {{FileSystem}} and {{FileContext}} are not completely 
 defined in terms of 
 # core expectations of a filesystem
 # consistency requirements.
 # concurrency requirements.
 # minimum scale limits
 Furthermore, methods are not defined strictly enough in terms of their 
 outcomes and failure modes.
 The requirements and method semantics should be defined more strictly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9574) Add new methods in AbstractDelegationTokenSecretManager for restoring RMDelegationTokens on RMRestart

2013-05-24 Thread Vinod Kumar Vavilapalli (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666867#comment-13666867
 ] 

Vinod Kumar Vavilapalli commented on HADOOP-9574:
-

Want to move forward with this for the sake of YARN-638.

Mostly looks good to me. Can you add tests to make sure these new APIs are 
correctly called? You can modify TestDelegationTokenSecretManager.

Also, a couple of simple tests for DelegationKey changes will be great.


 Add new methods in AbstractDelegationTokenSecretManager for restoring 
 RMDelegationTokens on RMRestart
 -

 Key: HADOOP-9574
 URL: https://issues.apache.org/jira/browse/HADOOP-9574
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Jian He
Assignee: Jian He
 Attachments: HADOOP-9574.1.patch


 we're considering to add the following methods in 
 AbstractDelegationTokenSecretManager for restoring RMDelegationTokens, these 
 methods can also possibly be reused by hdfsDelegationTokenSecretManager, see 
 YARN-638
   protected void storeNewMasterKey(DelegationKey key) throws IOException {
 return;
   }
   protected void removeStoredMasterKey(DelegationKey key) {
 return;
   }
   protected void storeNewToken(TokenIdent ident, long renewDate) {
 return;
   }
   protected void removeStoredToken(TokenIdent ident) throws IOException {
   }
   protected void updateStoredToken(TokenIdent ident, long renewDate) {
 return;
   }
 Also move addPersistedDelegationToken in hdfs.DelegationTokenSecretManager, 
 to AbstractDelegationTokenSecretManager

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9599) hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly

2013-05-24 Thread Chuan Liu (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666884#comment-13666884
 ] 

Chuan Liu commented on HADOOP-9599:
---

Judging from the context, I think it should be HADOOP_COMMON_HOME instead of 
HADOOP_HOME.
Because the purpose of the script is mainly to include JNI library, i.e. native 
library, in Java library path, and native library is a hadoop-common project.
I think it is also good to add some comments as well.

 hadoop-config.cmd doesn't set JAVA_LIBRARY_PATH correctly
 -

 Key: HADOOP-9599
 URL: https://issues.apache.org/jira/browse/HADOOP-9599
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9599.patch


 In Windows, hadoop-config.cmd uses the non-existent-variable HADOOP_CORE_HOME 
 when setting the JAVA_LIBRAR_PATH variable. It should use HADOOP_HOME.
 The net effect is that running e.g. hdfs namenode would error out with 
 UnsatisfiedLinkError because it can't access hadoop.dll.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9600) In Windows: Hadoop fails to run when JAVA_HOME has spaces in it

2013-05-24 Thread Chuan Liu (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666890#comment-13666890
 ] 

Chuan Liu commented on HADOOP-9600:
---

Thanks for the patch!

Why we need the following change?

{noformat}
-for /f delims= %%A in ('%JAVA% -Xmx32m %HADOOP_JAVA_PLATFORM_OPTS% 
-classpath %CLASSPATH% org.apache.hadoop.util.PlatformName') do set 
JAVA_PLATFORM=%%A
+%JAVA% -Xmx32m %HADOOP_JAVA_PLATFORM_OPTS% -classpath %CLASSPATH% 
org.apache.hadoop.util.PlatformName  %TEMP%\java_platforms.txt
+set /p JAVA_PLATFORM=%TEMP%\java_platforms.txt
+del %TEMP%\java_platforms.txt
 @rem replace space with underscore
 set JAVA_PLATFORM=%JAVA_PLATFORM: =_%
{noformat}

 In Windows: Hadoop fails to run when JAVA_HOME has spaces in it
 ---

 Key: HADOOP-9600
 URL: https://issues.apache.org/jira/browse/HADOOP-9600
 Project: Hadoop Common
  Issue Type: Bug
 Environment: Windows
Reporter: Mostafa Elhemali
Assignee: Mostafa Elhemali
 Attachments: HADOOP-9600.2.patch, HADOOP-9600.3.patch, 
 HADOOP-9600.patch


 hadoop-config.cmd misbehaves when JAVA_HOME has spaces in it (e.g. if Java is 
 in c:\Program Files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-8469) Make NetworkTopology class pluggable

2013-05-24 Thread Junping Du (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Junping Du updated HADOOP-8469:
---

Target Version/s: 2.0.5-beta  (was: 2.0.3-alpha)
  Status: Patch Available  (was: Reopened)

 Make NetworkTopology class pluggable
 

 Key: HADOOP-8469
 URL: https://issues.apache.org/jira/browse/HADOOP-8469
 Project: Hadoop Common
  Issue Type: Sub-task
Affects Versions: 2.0.0-alpha, 1.0.0
Reporter: Junping Du
Assignee: Junping Du
 Fix For: 3.0.0

 Attachments: HADOOP-8469-branch-2.patch, 
 HADOOP-8469-NetworkTopology-pluggable.patch, 
 HADOOP-8469-NetworkTopology-pluggable-v2.patch, 
 HADOOP-8469-NetworkTopology-pluggable-v3.patch, 
 HADOOP-8469-NetworkTopology-pluggable-v4.patch, 
 HADOOP-8469-NetworkTopology-pluggable-v5.patch


 The class NetworkTopology is where the three-layer hierarchical topology is 
 modeled in the current code base and is instantiated directly by the 
 DatanodeManager and Balancer.
 To support alternative topologies, changes were make the topology class 
 pluggable, that is to support using a user specified topology class specified 
 in the Hadoop configuration file core-defaul.xml. The user specified topology 
 class is instantiated using reflection in the same manner as other 
 customizable classes in Hadoop. If no use specified topology class is found, 
 the fallback is to use the NetworkTopology to preserve current behavior. To 
 make it possible to reuse code in NetworkTopology several minor changes were 
 made to make the class more extensible. The NetworkTopology class is 
 currently annotated with @InterfaceAudience.LimitedPrivate({HDFS, 
 MapReduce}) and @InterfaceStability.Unstable.
 The proposed changes in NetworkTopology listed below
 1. Some fields were changes from private to protected
 2. Added some protected methods so that sub classes could override behavior
 3. Added a new method,isNodeGroupAware,to NetworkTopology
 4. The inner class InnerNode was made a package protected class to it would 
 be easier to subclass

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-8469) Make NetworkTopology class pluggable

2013-05-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666901#comment-13666901
 ] 

Hadoop QA commented on HADOOP-8469:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12584625/HADOOP-8469-branch-2.patch
  against trunk revision .

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/2573//console

This message is automatically generated.

 Make NetworkTopology class pluggable
 

 Key: HADOOP-8469
 URL: https://issues.apache.org/jira/browse/HADOOP-8469
 Project: Hadoop Common
  Issue Type: Sub-task
Affects Versions: 1.0.0, 2.0.0-alpha
Reporter: Junping Du
Assignee: Junping Du
 Fix For: 3.0.0

 Attachments: HADOOP-8469-branch-2.patch, 
 HADOOP-8469-NetworkTopology-pluggable.patch, 
 HADOOP-8469-NetworkTopology-pluggable-v2.patch, 
 HADOOP-8469-NetworkTopology-pluggable-v3.patch, 
 HADOOP-8469-NetworkTopology-pluggable-v4.patch, 
 HADOOP-8469-NetworkTopology-pluggable-v5.patch


 The class NetworkTopology is where the three-layer hierarchical topology is 
 modeled in the current code base and is instantiated directly by the 
 DatanodeManager and Balancer.
 To support alternative topologies, changes were make the topology class 
 pluggable, that is to support using a user specified topology class specified 
 in the Hadoop configuration file core-defaul.xml. The user specified topology 
 class is instantiated using reflection in the same manner as other 
 customizable classes in Hadoop. If no use specified topology class is found, 
 the fallback is to use the NetworkTopology to preserve current behavior. To 
 make it possible to reuse code in NetworkTopology several minor changes were 
 made to make the class more extensible. The NetworkTopology class is 
 currently annotated with @InterfaceAudience.LimitedPrivate({HDFS, 
 MapReduce}) and @InterfaceStability.Unstable.
 The proposed changes in NetworkTopology listed below
 1. Some fields were changes from private to protected
 2. Added some protected methods so that sub classes could override behavior
 3. Added a new method,isNodeGroupAware,to NetworkTopology
 4. The inner class InnerNode was made a package protected class to it would 
 be easier to subclass

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9597) FileSystem open() API is not clear if FileNotFoundException is throw when the path does not exist

2013-05-24 Thread Konstantin Boudnik (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Boudnik updated HADOOP-9597:
---

Fix Version/s: (was: 2.0.4.1-alpha)

 FileSystem open() API is not clear if FileNotFoundException is throw when the 
 path does not exist
 -

 Key: HADOOP-9597
 URL: https://issues.apache.org/jira/browse/HADOOP-9597
 Project: Hadoop Common
  Issue Type: Sub-task
  Components: documentation, fs
Affects Versions: 2.0.4-alpha
Reporter: Jerry He
Priority: Minor

 The current FileSystem open() method throws a generic IOException in its API 
 specification.
 Some FileSystem implementations (DFS, RawLocalFileSystem ...) throws more 
 specific FileNotFoundException if the path does not exist.  Some throws 
 IOException only (FTPFileSystem, HftpFileSystem ...). 
 If we have a new FileSystem implementation, what should we follow exactly for 
 open()?
 What should the application expect in this case.
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9407) commons-daemon 1.0.3 dependency has bad group id causing build issues

2013-05-24 Thread Konstantin Boudnik (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konstantin Boudnik updated HADOOP-9407:
---

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Fixed in both targetted releases. CLosing.

 commons-daemon 1.0.3 dependency has bad group id causing build issues
 -

 Key: HADOOP-9407
 URL: https://issues.apache.org/jira/browse/HADOOP-9407
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Affects Versions: 2.0.3-alpha, 2.0.4-alpha
Reporter: Sangjin Lee
Assignee: Sangjin Lee
  Labels: 2.0.4
 Fix For: 2.0.5-beta, 2.0.4.1-alpha

 Attachments: HDFS-4497.patch


 The commons-daemon dependency of the hadoop-hdfs module has been at version 
 1.0.3 for a while. However, 1.0.3 has a pretty well-known groupId error in 
 its pom (org.apache.commons as opposed to commons-daemon). This problem 
 has since been corrected on commons-daemon starting 1.0.4.
 This causes build problems for many who depend on hadoop-hdfs directly and 
 indirectly, however. Maven can skip over this metadata inconsistency. But 
 other less forgiving build systems such as ivy and gradle have much harder 
 time working around this problem. For example, in gradle, pretty much the 
 only obvious way to work around this is to override this dependency version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9579) Contrib ant test target not setting the java.library.path

2013-05-24 Thread Chris Nauroth (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666949#comment-13666949
 ] 

Chris Nauroth commented on HADOOP-9579:
---

Chuan, my plan was to try running {{TestGridmixSubmission}} and check logs to 
see that {{NativeCodeLoader}} found the library.  Unfortunately, it failed with:

{quote}
13/05/24 10:41:00 ERROR util.Shell: Failed to detect a valid hadoop home directo
ry
java.io.IOException: HADOOP_HOME or hadoop.home.dir are not set.
{quote}

Specifically, I was running ant -Dwindows=true 
-Dtestcase=TestGridmixSubmission test-contrib from the root of the 
branch-1-win repo.  Ivan, is there something else that we need to do to verify 
this, or does this look like a problem?

 Contrib ant test target not setting the java.library.path
 -

 Key: HADOOP-9579
 URL: https://issues.apache.org/jira/browse/HADOOP-9579
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 1-win
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Attachments: HADOOP-9579.branch-1-win.patch


 build-contrib.xml does not set java.library.path causing tests to run without 
 the hadoop native library. This is a bigger problem on Windows as having the 
 native library is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HADOOP-9579) Contrib ant test target not setting the java.library.path

2013-05-24 Thread Ivan Mitic (JIRA)

 [ 
https://issues.apache.org/jira/browse/HADOOP-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Mitic updated HADOOP-9579:
---

Attachment: HADOOP-9579.branch-1-win.2.patch

Attaching the updated patch.

 Contrib ant test target not setting the java.library.path
 -

 Key: HADOOP-9579
 URL: https://issues.apache.org/jira/browse/HADOOP-9579
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 1-win
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Attachments: HADOOP-9579.branch-1-win.2.patch, 
 HADOOP-9579.branch-1-win.patch


 build-contrib.xml does not set java.library.path causing tests to run without 
 the hadoop native library. This is a bigger problem on Windows as having the 
 native library is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-9579) Contrib ant test target not setting the java.library.path

2013-05-24 Thread Ivan Mitic (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666956#comment-13666956
 ] 

Ivan Mitic commented on HADOOP-9579:


Thanks Chuan and Chris for reviewing!

Bq. Specifically, I was running ant -Dwindows=true 
-Dtestcase=TestGridmixSubmission test-contrib from the root of the 
branch-1-win repo. Ivan, is there something else that we need to do to verify 
this, or does this look like a problem?
I just took a quick look and indeed there is another (slightly orthogonal) 
problem here. Basically HADOOP_HOME is not set when contrib tests are run 
resulting in the above error. Looks like we did not catch this problem earlier 
because we set HADOOP_HOME as part of our build environment initialization. I 
went ahead and fixed this as part of this Jira since it’s also related to 
contrib tests on Windows (v2 patch). Good catch Chris!


 Contrib ant test target not setting the java.library.path
 -

 Key: HADOOP-9579
 URL: https://issues.apache.org/jira/browse/HADOOP-9579
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 1-win
Reporter: Ivan Mitic
Assignee: Ivan Mitic
 Attachments: HADOOP-9579.branch-1-win.2.patch, 
 HADOOP-9579.branch-1-win.patch


 build-contrib.xml does not set java.library.path causing tests to run without 
 the hadoop native library. This is a bigger problem on Windows as having the 
 native library is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HADOOP-8562) Enhancements to support Hadoop on Windows Server and Windows Azure environments

2013-05-24 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HADOOP-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666964#comment-13666964
 ] 

Hudson commented on HADOOP-8562:


Integrated in Hadoop-trunk-Commit #3790 (See 
[https://builds.apache.org/job/Hadoop-trunk-Commit/3790/])
Update hadoop-common CHANGES.txt after merging HADOOP-8562 (Revision 
1486288)

 Result = SUCCESS
suresh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1486288
Files : 
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt


 Enhancements to support Hadoop on Windows Server and Windows Azure 
 environments
 ---

 Key: HADOOP-8562
 URL: https://issues.apache.org/jira/browse/HADOOP-8562
 Project: Hadoop Common
  Issue Type: New Feature
Affects Versions: 3.0.0
Reporter: Bikas Saha
Assignee: Bikas Saha
 Fix For: 2.0.5-beta

 Attachments: branch-2.merge.patch, branch-2.merge.patch, 
 branch-trunk-win.min-notest.patch, branch-trunk-win-min.patch, 
 branch-trunk-win.min.patch, branch-trunk-win.patch, branch-trunk-win.patch, 
 branch-trunk-win.patch, branch-trunk-win.patch, branch-trunk-win.patch, 
 branch-trunk-win.patch, branch-trunk-win.patch, branch-trunk-win.patch, 
 branch-trunk-win.patch, branch-trunk-win.patch, branch-trunk-win.patch, 
 test-untar.tar, test-untar.tgz


 This JIRA tracks the work that needs to be done on trunk to enable Hadoop to 
 run on Windows Server and Azure environments. This incorporates porting 
 relevant work from the similar effort on branch 1 tracked via HADOOP-8079.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira