[jira] [Updated] (HADOOP-8252) Hashcode is logging while logging block report message
[ https://issues.apache.org/jira/browse/HADOOP-8252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HADOOP-8252: -- Attachment: Hadoop-8252.patch Patch addressing the improvements in the log message. No test case added as changes done only in the log message. Hashcode is logging while logging block report message -- Key: HADOOP-8252 URL: https://issues.apache.org/jira/browse/HADOOP-8252 Project: Hadoop Common Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Brahma Reddy Battula Priority: Trivial Attachments: Hadoop-8252.patch Scenario: = Start NN and DN. Check log messgae in DN..It's coming like following 2012-03-13 14:34:36,008 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: sent block report, processed command:org.apache.hadoop.hdfs.server.protocol.FinalizeCommand@43deff3 line num 413 in BpserviceActor.java LOG.info(sent block report, processed command: + cmd); line num 388 in BpserviceActor.java cmd = bpNamenode.blockReport(bpRegistration,bpos.getBlockPoolId(), report); It's better log message instead of hashcode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8307) The task-controller is not packaged in the tarball
[ https://issues.apache.org/jira/browse/HADOOP-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley updated HADOOP-8307: -- Attachment: hadoop-8307.patch The task-controller is not packaged in the tarball -- Key: HADOOP-8307 URL: https://issues.apache.org/jira/browse/HADOOP-8307 Project: Hadoop Common Issue Type: Bug Components: build Affects Versions: 1.0.3 Reporter: Owen O'Malley Assignee: Owen O'Malley Attachments: hadoop-8307.patch Ant in some situations, puts artifacts such as task-controller into the build/hadoop-*/ directory before the package target deletes it to start over. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8307) The task-controller is not packaged in the tarball
[ https://issues.apache.org/jira/browse/HADOOP-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley updated HADOOP-8307: -- Status: Patch Available (was: Open) The task-controller is not packaged in the tarball -- Key: HADOOP-8307 URL: https://issues.apache.org/jira/browse/HADOOP-8307 Project: Hadoop Common Issue Type: Bug Components: build Affects Versions: 1.0.3 Reporter: Owen O'Malley Assignee: Owen O'Malley Attachments: hadoop-8307.patch Ant in some situations, puts artifacts such as task-controller into the build/hadoop-*/ directory before the package target deletes it to start over. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8307) The task-controller is not packaged in the tarball
[ https://issues.apache.org/jira/browse/HADOOP-8307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260284#comment-13260284 ] Hadoop QA commented on HADOOP-8307: --- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12523932/hadoop-8307.patch against trunk revision . +1 @author. The patch does not contain any @author tags. -1 tests included. 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. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/882//console This message is automatically generated. The task-controller is not packaged in the tarball -- Key: HADOOP-8307 URL: https://issues.apache.org/jira/browse/HADOOP-8307 Project: Hadoop Common Issue Type: Bug Components: build Affects Versions: 1.0.3 Reporter: Owen O'Malley Assignee: Owen O'Malley Attachments: hadoop-8307.patch Ant in some situations, puts artifacts such as task-controller into the build/hadoop-*/ directory before the package target deletes it to start over. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8304) DNSToSwitchMapping should add interface to resolve individual host besides a list of host
[ https://issues.apache.org/jira/browse/HADOOP-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Junping Du updated HADOOP-8304: --- Attachment: HADOOP-8304.patch The patch to add resolve(String host) interface to DNSToSwitchMapping, and some related unit tests. Also, identify a potential bug that a hostname start with number may not been resolved properly. DNSToSwitchMapping should add interface to resolve individual host besides a list of host - Key: HADOOP-8304 URL: https://issues.apache.org/jira/browse/HADOOP-8304 Project: Hadoop Common Issue Type: Improvement Components: io Affects Versions: 1.0.0, 2.0.0 Reporter: Junping Du Assignee: Junping Du Fix For: 2.0.0 Attachments: HADOOP-8304.patch Original Estimate: 48h Remaining Estimate: 48h DNSToSwitchMapping now has only one API to resolve a host list: public ListString resolve(ListString names). But the two major caller: RackResolver.resolve() and DatanodeManager.resolveNetworkLocation() are taking single host name but have to wrapper it to an single entry ArrayList. This is not necessary especially the host has been cached before. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8304) DNSToSwitchMapping should add interface to resolve individual host besides a list of host
[ https://issues.apache.org/jira/browse/HADOOP-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Junping Du updated HADOOP-8304: --- Status: Patch Available (was: Open) DNSToSwitchMapping should add interface to resolve individual host besides a list of host - Key: HADOOP-8304 URL: https://issues.apache.org/jira/browse/HADOOP-8304 Project: Hadoop Common Issue Type: Improvement Components: io Affects Versions: 1.0.0, 2.0.0 Reporter: Junping Du Assignee: Junping Du Fix For: 2.0.0 Attachments: HADOOP-8304.patch Original Estimate: 48h Remaining Estimate: 48h DNSToSwitchMapping now has only one API to resolve a host list: public ListString resolve(ListString names). But the two major caller: RackResolver.resolve() and DatanodeManager.resolveNetworkLocation() are taking single host name but have to wrapper it to an single entry ArrayList. This is not necessary especially the host has been cached before. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8304) DNSToSwitchMapping should add interface to resolve individual host besides a list of host
[ https://issues.apache.org/jira/browse/HADOOP-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260306#comment-13260306 ] Hadoop QA commented on HADOOP-8304: --- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12523938/HADOOP-8304.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 7 new or modified test files. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/883//console This message is automatically generated. DNSToSwitchMapping should add interface to resolve individual host besides a list of host - Key: HADOOP-8304 URL: https://issues.apache.org/jira/browse/HADOOP-8304 Project: Hadoop Common Issue Type: Improvement Components: io Affects Versions: 1.0.0, 2.0.0 Reporter: Junping Du Assignee: Junping Du Fix For: 2.0.0 Attachments: HADOOP-8304.patch Original Estimate: 48h Remaining Estimate: 48h DNSToSwitchMapping now has only one API to resolve a host list: public ListString resolve(ListString names). But the two major caller: RackResolver.resolve() and DatanodeManager.resolveNetworkLocation() are taking single host name but have to wrapper it to an single entry ArrayList. This is not necessary especially the host has been cached before. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
Aaron T. Myers created HADOOP-8310: -- Summary: FileContext#checkPath should handle URIs with no port Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[ https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron T. Myers updated HADOOP-8310: --- Status: Patch Available (was: Open) FileContext#checkPath should handle URIs with no port - Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Attachments: HADOOP-8310.patch AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[ https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron T. Myers updated HADOOP-8310: --- Attachment: HADOOP-8310.patch Here's a patch which fixes the issue, by strictly comparing initially only the host components of the URIs, instead of the full authorities. FileContext#checkPath should handle URIs with no port - Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Attachments: HADOOP-8310.patch AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[ https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260367#comment-13260367 ] Hadoop QA commented on HADOOP-8310: --- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12523944/HADOOP-8310.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 1 new or modified test files. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 eclipse:eclipse. The patch built with eclipse:eclipse. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.fs.viewfs.TestViewFsTrash +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/884//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/884//console This message is automatically generated. FileContext#checkPath should handle URIs with no port - Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Attachments: HADOOP-8310.patch AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8284) clover integration broken, also mapreduce poms are pulling in clover as a dependency
[ https://issues.apache.org/jira/browse/HADOOP-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260504#comment-13260504 ] Hudson commented on HADOOP-8284: Integrated in Hadoop-Hdfs-trunk #1024 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk/1024/]) HADOOP-8284. clover integration broken, also mapreduce poms are pulling in clover as a dependency. (phunt via tucu) (Revision 1329490) Result = FAILURE tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329490 Files : * /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt * /hadoop/common/trunk/hadoop-project/pom.xml clover integration broken, also mapreduce poms are pulling in clover as a dependency Key: HADOOP-8284 URL: https://issues.apache.org/jira/browse/HADOOP-8284 Project: Hadoop Common Issue Type: Bug Components: build Reporter: Patrick Hunt Assignee: Patrick Hunt Attachments: HADOOP-8284.patch, HADOOP-8284.patch, HADOOP-8284.patch companion to MAPREDUCE-4141 - clover is broken on trunk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8152) Expand public APIs for security library classes
[ https://issues.apache.org/jira/browse/HADOOP-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260507#comment-13260507 ] Hudson commented on HADOOP-8152: Integrated in Hadoop-Hdfs-trunk #1024 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk/1024/]) HADOOP-8152. Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541) Result = FAILURE eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329541 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/security/SecurityUtil.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java Expand public APIs for security library classes --- Key: HADOOP-8152 URL: https://issues.apache.org/jira/browse/HADOOP-8152 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Fix For: 2.0.0 Attachments: HADOOP-8152.patch, HADOOP-8152.patch, HADOOP-8152.patch Currently projects like Hive and HBase use UserGroupInformation and SecurityUtil methods. Both of these classes are marked LimitedPrivate(HDFS,MR) but should probably be marked more generally public. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8285) Use ProtoBuf for RpcPayLoadHeader
[ https://issues.apache.org/jira/browse/HADOOP-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260505#comment-13260505 ] Hudson commented on HADOOP-8285: Integrated in Hadoop-Hdfs-trunk #1024 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk/1024/]) HADOOP-8285 Use ProtoBuf for RpcPayLoadHeader (sanjay radia) (Revision 1329319) Result = FAILURE sradia : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329319 Files : * /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt * /hadoop/common/trunk/hadoop-common-project/hadoop-common/dev-support/findbugsExcludeFile.xml * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/Client.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngine.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/ProtocolMetaInfoServerSideTranslatorPB.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RPC.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcClientUtil.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcPayloadHeader.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/Server.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/WritableRpcEngine.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/ProtoUtil.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/proto/RpcPayloadHeader.proto * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestIPC.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestIPCServerResponder.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestMultipleProtocolServer.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestProtoBufRpc.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestRPCCompatibility.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSUtil.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientDatanodeProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/DatanodeProtocolClientSideTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/GetUserMappingsProtocolClientSideTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/InterDatanodeProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/JournalProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/NamenodeProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/RefreshAuthorizationPolicyProtocolClientSideTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/RefreshUserMappingsProtocolClientSideTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/TestInterDatanodeProtocol.java * /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-common/src/main/java/org/apache/hadoop/yarn/factories/impl/pb/RpcServerFactoryPBImpl.java Use ProtoBuf for RpcPayLoadHeader - Key: HADOOP-8285 URL: https://issues.apache.org/jira/browse/HADOOP-8285 Project: Hadoop Common Issue Type: Improvement Components: ipc Reporter: Sanjay Radia Assignee: Sanjay Radia Attachments: hadoop-8285-1-common.patch, hadoop-8285-1.patch, hadoop-8285-2-common.patch, hadoop-8285-2.patch, hadoop-8285-3-common.patch, hadoop-8285-3.patch,
[jira] [Commented] (HADOOP-8284) clover integration broken, also mapreduce poms are pulling in clover as a dependency
[ https://issues.apache.org/jira/browse/HADOOP-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260530#comment-13260530 ] Hudson commented on HADOOP-8284: Integrated in Hadoop-Mapreduce-trunk #1059 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1059/]) HADOOP-8284. clover integration broken, also mapreduce poms are pulling in clover as a dependency. (phunt via tucu) (Revision 1329490) Result = FAILURE tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329490 Files : * /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt * /hadoop/common/trunk/hadoop-project/pom.xml clover integration broken, also mapreduce poms are pulling in clover as a dependency Key: HADOOP-8284 URL: https://issues.apache.org/jira/browse/HADOOP-8284 Project: Hadoop Common Issue Type: Bug Components: build Reporter: Patrick Hunt Assignee: Patrick Hunt Attachments: HADOOP-8284.patch, HADOOP-8284.patch, HADOOP-8284.patch companion to MAPREDUCE-4141 - clover is broken on trunk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8152) Expand public APIs for security library classes
[ https://issues.apache.org/jira/browse/HADOOP-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260533#comment-13260533 ] Hudson commented on HADOOP-8152: Integrated in Hadoop-Mapreduce-trunk #1059 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1059/]) HADOOP-8152. Expand public APIs for security library classes. Contributed by Aaron T. Myers (Revision 1329541) Result = FAILURE eli : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329541 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/security/SecurityUtil.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java Expand public APIs for security library classes --- Key: HADOOP-8152 URL: https://issues.apache.org/jira/browse/HADOOP-8152 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Fix For: 2.0.0 Attachments: HADOOP-8152.patch, HADOOP-8152.patch, HADOOP-8152.patch Currently projects like Hive and HBase use UserGroupInformation and SecurityUtil methods. Both of these classes are marked LimitedPrivate(HDFS,MR) but should probably be marked more generally public. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8285) Use ProtoBuf for RpcPayLoadHeader
[ https://issues.apache.org/jira/browse/HADOOP-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260531#comment-13260531 ] Hudson commented on HADOOP-8285: Integrated in Hadoop-Mapreduce-trunk #1059 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1059/]) HADOOP-8285 Use ProtoBuf for RpcPayLoadHeader (sanjay radia) (Revision 1329319) Result = FAILURE sradia : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329319 Files : * /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt * /hadoop/common/trunk/hadoop-common-project/hadoop-common/dev-support/findbugsExcludeFile.xml * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/Client.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/ProtobufRpcEngine.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/ProtocolMetaInfoServerSideTranslatorPB.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RPC.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcClientUtil.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcPayloadHeader.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/Server.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/WritableRpcEngine.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/ProtoUtil.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/proto/RpcPayloadHeader.proto * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestIPC.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestIPCServerResponder.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestMultipleProtocolServer.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestProtoBufRpc.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ipc/TestRPCCompatibility.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSUtil.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientDatanodeProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/ClientNamenodeProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/DatanodeProtocolClientSideTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/GetUserMappingsProtocolClientSideTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/InterDatanodeProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/JournalProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/NamenodeProtocolTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/RefreshAuthorizationPolicyProtocolClientSideTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocolPB/RefreshUserMappingsProtocolClientSideTranslatorPB.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDFSClientRetries.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/server/datanode/fsdataset/impl/TestInterDatanodeProtocol.java * /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-yarn/hadoop-yarn-common/src/main/java/org/apache/hadoop/yarn/factories/impl/pb/RpcServerFactoryPBImpl.java Use ProtoBuf for RpcPayLoadHeader - Key: HADOOP-8285 URL: https://issues.apache.org/jira/browse/HADOOP-8285 Project: Hadoop Common Issue Type: Improvement Components: ipc Reporter: Sanjay Radia Assignee: Sanjay Radia Attachments: hadoop-8285-1-common.patch, hadoop-8285-1.patch, hadoop-8285-2-common.patch, hadoop-8285-2.patch, hadoop-8285-3-common.patch, hadoop-8285-3.patch,
[jira] [Updated] (HADOOP-8309) Pseudo Kerberos AuthenticationHandler should use getType() to create token
[ https://issues.apache.org/jira/browse/HADOOP-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Abdelnur updated HADOOP-8309: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) committed to trunk and branch-2 Pseudo Kerberos AuthenticationHandler should use getType() to create token Key: HADOOP-8309 URL: https://issues.apache.org/jira/browse/HADOOP-8309 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8309.patch Currently they use the constant TYPE, this means that if AuthenticationHandler are subclassed a new type cannot be used. Instead they should use the getType() method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8309) Pseudo Kerberos AuthenticationHandler should use getType() to create token
[ https://issues.apache.org/jira/browse/HADOOP-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260561#comment-13260561 ] Hudson commented on HADOOP-8309: Integrated in Hadoop-Common-trunk-Commit #2125 (See [https://builds.apache.org/job/Hadoop-Common-trunk-Commit/2125/]) HADOOP-8309. Pseudo Kerberos AuthenticationHandler should use getType() to create token (tucu) (Revision 1329713) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329713 Files : * /hadoop/common/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/KerberosAuthenticationHandler.java * /hadoop/common/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/PseudoAuthenticationHandler.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt Pseudo Kerberos AuthenticationHandler should use getType() to create token Key: HADOOP-8309 URL: https://issues.apache.org/jira/browse/HADOOP-8309 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8309.patch Currently they use the constant TYPE, this means that if AuthenticationHandler are subclassed a new type cannot be used. Instead they should use the getType() method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8309) Pseudo Kerberos AuthenticationHandler should use getType() to create token
[ https://issues.apache.org/jira/browse/HADOOP-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260559#comment-13260559 ] Hudson commented on HADOOP-8309: Integrated in Hadoop-Hdfs-trunk-Commit #2199 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/2199/]) HADOOP-8309. Pseudo Kerberos AuthenticationHandler should use getType() to create token (tucu) (Revision 1329713) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329713 Files : * /hadoop/common/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/KerberosAuthenticationHandler.java * /hadoop/common/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/PseudoAuthenticationHandler.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt Pseudo Kerberos AuthenticationHandler should use getType() to create token Key: HADOOP-8309 URL: https://issues.apache.org/jira/browse/HADOOP-8309 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8309.patch Currently they use the constant TYPE, this means that if AuthenticationHandler are subclassed a new type cannot be used. Instead they should use the getType() method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8309) Pseudo Kerberos AuthenticationHandler should use getType() to create token
[ https://issues.apache.org/jira/browse/HADOOP-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260581#comment-13260581 ] Hudson commented on HADOOP-8309: Integrated in Hadoop-Mapreduce-trunk-Commit #2141 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Commit/2141/]) HADOOP-8309. Pseudo Kerberos AuthenticationHandler should use getType() to create token (tucu) (Revision 1329713) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329713 Files : * /hadoop/common/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/KerberosAuthenticationHandler.java * /hadoop/common/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/PseudoAuthenticationHandler.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt Pseudo Kerberos AuthenticationHandler should use getType() to create token Key: HADOOP-8309 URL: https://issues.apache.org/jira/browse/HADOOP-8309 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8309.patch Currently they use the constant TYPE, this means that if AuthenticationHandler are subclassed a new type cannot be used. Instead they should use the getType() method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8227) Allow RPC to limit ephemeral port range.
[ https://issues.apache.org/jira/browse/HADOOP-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Joseph Evans updated HADOOP-8227: Resolution: Fixed Fix Version/s: 0.23.3 Status: Resolved (was: Patch Available) Tom just checked the full patch into branch-0.23 as well so resolving this. Allow RPC to limit ephemeral port range. Key: HADOOP-8227 URL: https://issues.apache.org/jira/browse/HADOOP-8227 Project: Hadoop Common Issue Type: Improvement Affects Versions: 0.23.2 Reporter: Robert Joseph Evans Assignee: Robert Joseph Evans Priority: Blocker Fix For: 0.23.3, 2.0.0, 3.0.0 Attachments: HADOOP-8227-trunk.txt, HADOOP-8227-trunk.txt, HADOOP-8227-trunk.txt This is a sub task of MAPREDUCE-4079. For security reasons we would like to limit the range of ports that are used when some RPC servers select a port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[ https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260633#comment-13260633 ] John George commented on HADOOP-8310: - Good catch Aaron. +1 as long as the test failure is unrelated. FileContext#checkPath should handle URIs with no port - Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Attachments: HADOOP-8310.patch AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-8311) FSInputStream's positioned read fails to check seek
Daryn Sharp created HADOOP-8311:
---
Summary: FSInputStream's positioned read fails to check seek
Key: HADOOP-8311
URL: https://issues.apache.org/jira/browse/HADOOP-8311
Project: Hadoop Common
Issue Type: Bug
Affects Versions: 0.23.3, 0.24.0, 2.0.0
Reporter: Daryn Sharp
{{FSInputStream#read(long, byte[], int, int)}} will seek into the input stream,
but does not check that the seek actually succeeded.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[ https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260752#comment-13260752 ] Aaron T. Myers commented on HADOOP-8310: Thanks a lot for the review, John. I'm confident that the test failure of TestViewFsTrash is unrelated. I should also mention that I discovered this issue because without this fix one cannot view the conf page of a running MR2 job in a cluster whose fs.default.name is configured without a port. I manually verified that with this fix, one can get to the page just fine. I also ran the full HDFS test suite with this patch applied and everything passed. FileContext#checkPath should handle URIs with no port - Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Attachments: HADOOP-8310.patch AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[
https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260773#comment-13260773
]
Daryn Sharp commented on HADOOP-8310:
-
{{AbstractFileSystem}} should use the same implementation as {{FileSystem}}.
This patch doesn't appear to support canonicalization correctly.
FileContext#checkPath should handle URIs with no port
-
Key: HADOOP-8310
URL: https://issues.apache.org/jira/browse/HADOOP-8310
Project: Hadoop Common
Issue Type: Bug
Components: fs
Affects Versions: 2.0.0
Reporter: Aaron T. Myers
Assignee: Aaron T. Myers
Attachments: HADOOP-8310.patch
AbstractFileSystem#checkPath is used to verify that a given path is for the
same file system as represented by the AbstractFileSystem instance.
The original intent of the code was to allow for no port to be provided in
the checked path, if the default port was being used by the
AbstractFileSystem instance. However, before performing port handling,
AFS#checkPath compares the full URI authorities for equality. Since the URI
authority includes the port, the port handling code is never reached, and
thus valid paths may be erroneously considered invalid.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HADOOP-3977) SequenceFile.Writer reopen (hdfs append)
[ https://issues.apache.org/jira/browse/HADOOP-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J resolved HADOOP-3977. - Resolution: Duplicate A fresher effort is ongoing at HADOOP-7139 (Resolving as duplicate) SequenceFile.Writer reopen (hdfs append) Key: HADOOP-3977 URL: https://issues.apache.org/jira/browse/HADOOP-3977 Project: Hadoop Common Issue Type: Improvement Components: io Reporter: Karl Wettin Assignee: Karl Wettin Priority: Minor Attachments: HADOOP-3977.txt, HADOOP-3977.txt Allows for reopening and appending to a SequenceFile -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[ https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260827#comment-13260827 ] Aaron T. Myers commented on HADOOP-8310: bq. AbstractFileSystem should use the same implementation as FileSystem. The same implementation of checkPath? bq. This patch doesn't appear to support canonicalization correctly. I don't follow. This patch doesn't change canonicalization at all. FileContext#checkPath should handle URIs with no port - Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Attachments: HADOOP-8310.patch AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8296) hadoop/yarn daemonlog usage wrong
[ https://issues.apache.org/jira/browse/HADOOP-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260829#comment-13260829 ] Uma Maheswara Rao G commented on HADOOP-8296: - Thanks Deva, patch looks good. @Thomas, do you have any comments? hadoop/yarn daemonlog usage wrong -- Key: HADOOP-8296 URL: https://issues.apache.org/jira/browse/HADOOP-8296 Project: Hadoop Common Issue Type: Bug Affects Versions: 0.23.2, 2.0.0, 3.0.0 Reporter: Thomas Graves Assignee: Devaraj K Priority: Minor Attachments: HADOOP-8296.patch $ yarn daemonlog USAGES: java org.apache.hadoop.log.LogLevel -getlevel host:port name java org.apache.hadoop.log.LogLevel -setlevel host:port name level The usage shouldn't print java org.apache.hadoop.log.LogLevel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-8312) testpatch.sh should provide a simpler way to see which warnings changed
Robert Joseph Evans created HADOOP-8312: --- Summary: testpatch.sh should provide a simpler way to see which warnings changed Key: HADOOP-8312 URL: https://issues.apache.org/jira/browse/HADOOP-8312 Project: Hadoop Common Issue Type: Improvement Reporter: Robert Joseph Evans Assignee: Robert Joseph Evans test-patch.sh reports that a specific number of warnings has changed but it does not provide an easy way to see which ones have changed. For at least the javac warnings we should be able to provide a diff of the warnings in addition to the total count, because we capture the full compile log both before and after applying the patch. For javadoc warnings it would be nice to be able to provide a filtered list of the warnings based off of the files that were modified in the patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-8313) Add the ability for MetricsRegistry to remove metrics
Elliott Clark created HADOOP-8313: - Summary: Add the ability for MetricsRegistry to remove metrics Key: HADOOP-8313 URL: https://issues.apache.org/jira/browse/HADOOP-8313 Project: Hadoop Common Issue Type: Improvement Components: metrics Reporter: Elliott Clark Currently HBase is exposing metrics about a region through org.apache.hadoop.metrics. As regions are moved around or deleted we will want to remove the metrics. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-7549) Use JDK ServiceLoader mechanism to find FileSystem implementations
[ https://issues.apache.org/jira/browse/HADOOP-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260862#comment-13260862 ] Tom White commented on HADOOP-7549: --- +1 This looks good to me. Existing configurations will still work with this patch, so there are no compatibility concerns. Use JDK ServiceLoader mechanism to find FileSystem implementations -- Key: HADOOP-7549 URL: https://issues.apache.org/jira/browse/HADOOP-7549 Project: Hadoop Common Issue Type: Improvement Components: fs Affects Versions: 0.23.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 0.24.0 Attachments: HADOOP-7549v1.patch, HADOOP-7549v2.patch, HADOOP-7549v3.patch Currently configuring FileSystem implementations must be done by declaring the FileSystem class in the Hadoop configuration files (core-default.xml, ...). Using JDK ServiceLoader mechanism this configuration step can be avoided. Adding the JAR file with the additional FileSystem implementation would suffice. This is similar to what is being proposed for compression codecs (HADOOP-7350). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HADOOP-8306) ZKFC: improve error message when ZK is not running
[ https://issues.apache.org/jira/browse/HADOOP-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon resolved HADOOP-8306. - Resolution: Fixed Fix Version/s: Auto Failover (HDFS-3042) Hadoop Flags: Reviewed Committed to branch, thanks Eli ZKFC: improve error message when ZK is not running -- Key: HADOOP-8306 URL: https://issues.apache.org/jira/browse/HADOOP-8306 Project: Hadoop Common Issue Type: Improvement Components: auto-failover, ha Affects Versions: Auto Failover (HDFS-3042) Reporter: Todd Lipcon Assignee: Todd Lipcon Priority: Minor Fix For: Auto Failover (HDFS-3042) Attachments: hadoop-8306.txt Currently if you start the ZKFC without starting ZK, you get an ugly stack trace. We should improve the error message and give it a unique exit code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8008) Document how to change the default loglevels
[ https://issues.apache.org/jira/browse/HADOOP-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260884#comment-13260884 ] Eli Collins commented on HADOOP-8008: - Hi Tomohiko, I gave you perms to edit the wiki. Thanks, Eli Document how to change the default loglevels Key: HADOOP-8008 URL: https://issues.apache.org/jira/browse/HADOOP-8008 Project: Hadoop Common Issue Type: Improvement Components: documentation Reporter: Eli Collins Assignee: Tomohiko Kinebuchi Labels: newbie The hadoop.root.logger defined in log4j.properties is only used by applications. The scripts (bin and daemons) always set it to HADOOP_ROOT_LOGGER or INFO,console so the installed log4j.properties appears to be ignored. The wiki doesn't cover this: http://wiki.apache.org/hadoop/HowToConfigure We should update the cluster setup docs to indicate how the loglevel is configured and also add a comment in log4j.properties that the hadoop.root.logger defined there is not used by Hadoop itself, that HADOOP_ROOT_LOGGER must be set. This is relevant for commands and daemons, though the latter also has daemonlog (http://hadoop.apache.org/common/docs/current/commands_manual.html#daemonlog). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[
https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260887#comment-13260887
]
Daryn Sharp commented on HADOOP-8310:
-
bq. The same implementation of checkPath?
Yes, {{FileSystem#checkPath}} has code to handle host canonicalization that
works in conjunction with host-based tokens. It's an oversight on my part that
it didn't make it into {{FileContext}}...
FileContext#checkPath should handle URIs with no port
-
Key: HADOOP-8310
URL: https://issues.apache.org/jira/browse/HADOOP-8310
Project: Hadoop Common
Issue Type: Bug
Components: fs
Affects Versions: 2.0.0
Reporter: Aaron T. Myers
Assignee: Aaron T. Myers
Attachments: HADOOP-8310.patch
AbstractFileSystem#checkPath is used to verify that a given path is for the
same file system as represented by the AbstractFileSystem instance.
The original intent of the code was to allow for no port to be provided in
the checked path, if the default port was being used by the
AbstractFileSystem instance. However, before performing port handling,
AFS#checkPath compares the full URI authorities for equality. Since the URI
authority includes the port, the port handling code is never reached, and
thus valid paths may be erroneously considered invalid.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[ https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260890#comment-13260890 ] John George commented on HADOOP-8310: - @Daryn - do you think that should be handled as part of another JIRA since this specifically addresses a different issue? FileContext#checkPath should handle URIs with no port - Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Attachments: HADOOP-8310.patch AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-7549) Use JDK ServiceLoader mechanism to find FileSystem implementations
[ https://issues.apache.org/jira/browse/HADOOP-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Abdelnur updated HADOOP-7549: --- Resolution: Fixed Fix Version/s: (was: 0.24.0) 2.0.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) committed to trunk and branch-2. (committed v2 as v3 which is identical was missing the service files) Use JDK ServiceLoader mechanism to find FileSystem implementations -- Key: HADOOP-7549 URL: https://issues.apache.org/jira/browse/HADOOP-7549 Project: Hadoop Common Issue Type: Improvement Components: fs Affects Versions: 0.23.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-7549v1.patch, HADOOP-7549v2.patch, HADOOP-7549v3.patch Currently configuring FileSystem implementations must be done by declaring the FileSystem class in the Hadoop configuration files (core-default.xml, ...). Using JDK ServiceLoader mechanism this configuration step can be avoided. Adding the JAR file with the additional FileSystem implementation would suffice. This is similar to what is being proposed for compression codecs (HADOOP-7350). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-7549) Use JDK ServiceLoader mechanism to find FileSystem implementations
[ https://issues.apache.org/jira/browse/HADOOP-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260995#comment-13260995 ] Hudson commented on HADOOP-7549: Integrated in Hadoop-Hdfs-trunk-Commit #2200 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/2200/]) HADOOP-7549. Use JDK ServiceLoader mechanism to find FileSystem implementations. (tucu) (Revision 1329994) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329994 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/fs/FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/HarFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/LocalFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/ftp/FTPFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/kfs/KosmosFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/s3/S3FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/s3native/NativeS3FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/resources/META-INF/services/org.apache.hadoop.fs.FileSystem * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/resources/core-default.xml * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/TestFileSystemCaching.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/TestFilterFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/HftpFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/HsftpFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/web/WebHdfsFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/resources/META-INF/services/org.apache.hadoop.fs.FileSystem Use JDK ServiceLoader mechanism to find FileSystem implementations -- Key: HADOOP-7549 URL: https://issues.apache.org/jira/browse/HADOOP-7549 Project: Hadoop Common Issue Type: Improvement Components: fs Affects Versions: 0.23.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-7549v1.patch, HADOOP-7549v2.patch, HADOOP-7549v3.patch Currently configuring FileSystem implementations must be done by declaring the FileSystem class in the Hadoop configuration files (core-default.xml, ...). Using JDK ServiceLoader mechanism this configuration step can be avoided. Adding the JAR file with the additional FileSystem implementation would suffice. This is similar to what is being proposed for compression codecs (HADOOP-7350). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-7549) Use JDK ServiceLoader mechanism to find FileSystem implementations
[ https://issues.apache.org/jira/browse/HADOOP-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260999#comment-13260999 ] Hudson commented on HADOOP-7549: Integrated in Hadoop-Common-trunk-Commit #2126 (See [https://builds.apache.org/job/Hadoop-Common-trunk-Commit/2126/]) HADOOP-7549. Use JDK ServiceLoader mechanism to find FileSystem implementations. (tucu) (Revision 1329994) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329994 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/fs/FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/HarFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/LocalFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/ftp/FTPFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/kfs/KosmosFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/s3/S3FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/s3native/NativeS3FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/resources/META-INF/services/org.apache.hadoop.fs.FileSystem * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/resources/core-default.xml * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/TestFileSystemCaching.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/TestFilterFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/HftpFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/HsftpFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/web/WebHdfsFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/resources/META-INF/services/org.apache.hadoop.fs.FileSystem Use JDK ServiceLoader mechanism to find FileSystem implementations -- Key: HADOOP-7549 URL: https://issues.apache.org/jira/browse/HADOOP-7549 Project: Hadoop Common Issue Type: Improvement Components: fs Affects Versions: 0.23.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-7549v1.patch, HADOOP-7549v2.patch, HADOOP-7549v3.patch Currently configuring FileSystem implementations must be done by declaring the FileSystem class in the Hadoop configuration files (core-default.xml, ...). Using JDK ServiceLoader mechanism this configuration step can be avoided. Adding the JAR file with the additional FileSystem implementation would suffice. This is similar to what is being proposed for compression codecs (HADOOP-7350). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-7549) Use JDK ServiceLoader mechanism to find FileSystem implementations
[ https://issues.apache.org/jira/browse/HADOOP-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261009#comment-13261009 ] Hudson commented on HADOOP-7549: Integrated in Hadoop-Mapreduce-trunk-Commit #2142 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Commit/2142/]) HADOOP-7549. Use JDK ServiceLoader mechanism to find FileSystem implementations. (tucu) (Revision 1329994) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1329994 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/fs/FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/HarFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/LocalFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/ftp/FTPFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/kfs/KosmosFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/s3/S3FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/s3native/NativeS3FileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/resources/META-INF/services/org.apache.hadoop.fs.FileSystem * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/resources/core-default.xml * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/TestFileSystemCaching.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/TestFilterFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DistributedFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/HftpFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/HsftpFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/web/WebHdfsFileSystem.java * /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/resources/META-INF/services/org.apache.hadoop.fs.FileSystem Use JDK ServiceLoader mechanism to find FileSystem implementations -- Key: HADOOP-7549 URL: https://issues.apache.org/jira/browse/HADOOP-7549 Project: Hadoop Common Issue Type: Improvement Components: fs Affects Versions: 0.23.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-7549v1.patch, HADOOP-7549v2.patch, HADOOP-7549v3.patch Currently configuring FileSystem implementations must be done by declaring the FileSystem class in the Hadoop configuration files (core-default.xml, ...). Using JDK ServiceLoader mechanism this configuration step can be avoided. Adding the JAR file with the additional FileSystem implementation would suffice. This is similar to what is being proposed for compression codecs (HADOOP-7350). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8310) FileContext#checkPath should handle URIs with no port
[ https://issues.apache.org/jira/browse/HADOOP-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261050#comment-13261050 ] Aaron T. Myers commented on HADOOP-8310: bq. @Daryn - do you think that should be handled as part of another JIRA since this specifically addresses a different issue? That would be my preference as well. Making FC use FS's checkPath implementation is a bigger, potentially more destabilizing change. It's also not obvious to me that such a change would be entirely compatible, consdering FS#checkPath currently throws IllegalArgEx, whereas FC throws InvalidPathEx. Perhaps we can commit this patch as-is, and open another JIRA to make the two methods share code. Is that OK by you, Daryn? FileContext#checkPath should handle URIs with no port - Key: HADOOP-8310 URL: https://issues.apache.org/jira/browse/HADOOP-8310 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.0.0 Reporter: Aaron T. Myers Assignee: Aaron T. Myers Attachments: HADOOP-8310.patch AbstractFileSystem#checkPath is used to verify that a given path is for the same file system as represented by the AbstractFileSystem instance. The original intent of the code was to allow for no port to be provided in the checked path, if the default port was being used by the AbstractFileSystem instance. However, before performing port handling, AFS#checkPath compares the full URI authorities for equality. Since the URI authority includes the port, the port handling code is never reached, and thus valid paths may be erroneously considered invalid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8294) IPC Connection becomes unusable even if server address was temporarilly unresolvable
[ https://issues.apache.org/jira/browse/HADOOP-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Foley updated HADOOP-8294: --- Resolution: Fixed Fix Version/s: (was: 1.1.0) Status: Resolved (was: Patch Available) IPC Connection becomes unusable even if server address was temporarilly unresolvable Key: HADOOP-8294 URL: https://issues.apache.org/jira/browse/HADOOP-8294 Project: Hadoop Common Issue Type: Bug Components: ipc Affects Versions: 1.0.2 Reporter: Kihwal Lee Assignee: Kihwal Lee Priority: Critical Fix For: 1.0.3 Attachments: hadoop-8294.patch This is same as HADOOP-7428, but was observed on 1.x data nodes. This can happen more frequently after HADOOP-7472, which allows IPC Connection to re-resolve the name. HADOOP-7428 needs to be back-ported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8294) IPC Connection becomes unusable even if server address was temporarilly unresolvable
[ https://issues.apache.org/jira/browse/HADOOP-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261070#comment-13261070 ] Matt Foley commented on HADOOP-8294: +1. Committed to branch-1 and branch-1.0. IPC Connection becomes unusable even if server address was temporarilly unresolvable Key: HADOOP-8294 URL: https://issues.apache.org/jira/browse/HADOOP-8294 Project: Hadoop Common Issue Type: Bug Components: ipc Affects Versions: 1.0.2 Reporter: Kihwal Lee Assignee: Kihwal Lee Priority: Critical Fix For: 1.0.3 Attachments: hadoop-8294.patch This is same as HADOOP-7428, but was observed on 1.x data nodes. This can happen more frequently after HADOOP-7472, which allows IPC Connection to re-resolve the name. HADOOP-7428 needs to be back-ported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[ https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Abdelnur updated HADOOP-8314: --- Status: Patch Available (was: Open) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated --- Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
Alejandro Abdelnur created HADOOP-8314: -- Summary: HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[ https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Abdelnur updated HADOOP-8314: --- Attachment: HADOOP-8314.patch HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated --- Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[
https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261145#comment-13261145
]
Aaron T. Myers commented on HADOOP-8314:
Patch looks pretty good to me, Tucu. One small comment. This should either say
either users are not authorized or users are unauthorized but _not_ users
are not unauthorized. :)
{code}
+ response.sendError(HttpServletResponse.SC_UNAUTHORIZED,
+ Unauthenticated users are not +
+ unauthorized to access this page.);
{code}
Otherwise the patch looks good. +1 pending Jenkins.
HttpServer#hasAdminAccess should return false if authorization is enabled but
user is not authenticated
---
Key: HADOOP-8314
URL: https://issues.apache.org/jira/browse/HADOOP-8314
Project: Hadoop Common
Issue Type: Bug
Components: security
Affects Versions: 2.0.0, 3.0.0
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
Fix For: 2.0.0
Attachments: HADOOP-8314.patch
If the user is not authenticated (request.getRemoteUser() returns NULL) or
there is not authentication filter configured (thus returning also NULL),
hasAdminAccess should return false. Note that a filter could allow anonymous
access, thus the first case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[ https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261146#comment-13261146 ] Hadoop QA commented on HADOOP-8314: --- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12524080/HADOOP-8314.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 1 new or modified test files. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 eclipse:eclipse. The patch built with eclipse:eclipse. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed unit tests in . +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/885//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/885//console This message is automatically generated. HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated --- Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[ https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Abdelnur updated HADOOP-8314: --- Attachment: HADOOP-8314.patch attaching patch with ATM's suggestion HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated --- Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch, HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[ https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Abdelnur updated HADOOP-8314: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) committed to trunk and branch-2 HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated --- Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch, HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[ https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261264#comment-13261264 ] Hudson commented on HADOOP-8314: Integrated in Hadoop-Hdfs-trunk-Commit #2202 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/2202/]) HADOOP-8314. HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated. (tucu) (Revision 1330086) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1330086 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/http/HttpServer.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/http/TestHttpServer.java HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated --- Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch, HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[ https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261265#comment-13261265 ] Hudson commented on HADOOP-8314: Integrated in Hadoop-Common-trunk-Commit #2128 (See [https://builds.apache.org/job/Hadoop-Common-trunk-Commit/2128/]) HADOOP-8314. HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated. (tucu) (Revision 1330086) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1330086 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/http/HttpServer.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/http/TestHttpServer.java HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated --- Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch, HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-7940) method clear() in org.apache.hadoop.io.Text does not work
[
https://issues.apache.org/jira/browse/HADOOP-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261271#comment-13261271
]
Jim Donofrio commented on HADOOP-7940:
--
toString, getLength and other Text methods behave correctly after clear(). This
will hurt the performance of the class when calling append often and then clear
because you wont be able to use the byte array size that you had previously
scaled up to.
I dont think there was any expectation that getBytes would return a 0 length
array, it says right in the javadoc: Returns the raw bytes; however, only data
up to {@link #getLength()} is valid. which in this case is valid, 0 of the
bytes are valid
method clear() in org.apache.hadoop.io.Text does not work
-
Key: HADOOP-7940
URL: https://issues.apache.org/jira/browse/HADOOP-7940
Project: Hadoop Common
Issue Type: Bug
Components: io
Affects Versions: 0.20.205.0
Environment: Ubuntu, hadoop cloudera CDH3U2, Oracle SUN JDK 6U30
Reporter: Aaron,
Assignee: Csaba Miklos
Labels: patch
Fix For: 2.0.0
Attachments: HADOOP-7940.patch
Original Estimate: 2h
Remaining Estimate: 2h
LineReader reader = new LineReader(in, 4096);
...
Text text = new Text();
while((reader.readLine(text)) 0) {
...
text.clear();
}
}
Even the clear() method is called each time, some bytes are still not filled
as zero.
So, when reader.readLine(text) is called in a loop, some bytes are dirty
which was from last call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8279) Auto-HA: Allow manual failover to be invoked from zkfc.
[ https://issues.apache.org/jira/browse/HADOOP-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon updated HADOOP-8279: Attachment: hadoop-8279.txt Updated patch against tip of branch. Also amended the docs to reflect this improvement. Auto-HA: Allow manual failover to be invoked from zkfc. --- Key: HADOOP-8279 URL: https://issues.apache.org/jira/browse/HADOOP-8279 Project: Hadoop Common Issue Type: Improvement Components: ha Affects Versions: Auto Failover (HDFS-3042) Reporter: Mingjie Lai Assignee: Todd Lipcon Fix For: Auto Failover (HDFS-3042) Attachments: hadoop-8279.txt, hadoop-8279.txt, hadoop-8279.txt, hadoop-8279.txt HADOOP-8247 introduces a configure flag to prevent potential status inconsistency between zkfc and namenode, by making auto and manual failover mutually exclusive. However, as described in 2.7.2 section of design doc at HDFS-2185, we should allow manual and auto failover co-exist, by: - adding some rpc interfaces at zkfc - manual failover shall be triggered by haadmin, and handled by zkfc if auto failover is enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8314) HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated
[ https://issues.apache.org/jira/browse/HADOOP-8314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261272#comment-13261272 ] Hudson commented on HADOOP-8314: Integrated in Hadoop-Mapreduce-trunk-Commit #2144 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Commit/2144/]) HADOOP-8314. HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated. (tucu) (Revision 1330086) Result = SUCCESS tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1330086 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/http/HttpServer.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/http/TestHttpServer.java HttpServer#hasAdminAccess should return false if authorization is enabled but user is not authenticated --- Key: HADOOP-8314 URL: https://issues.apache.org/jira/browse/HADOOP-8314 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 2.0.0, 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 2.0.0 Attachments: HADOOP-8314.patch, HADOOP-8314.patch If the user is not authenticated (request.getRemoteUser() returns NULL) or there is not authentication filter configured (thus returning also NULL), hasAdminAccess should return false. Note that a filter could allow anonymous access, thus the first case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-7940) method clear() in org.apache.hadoop.io.Text does not work
[
https://issues.apache.org/jira/browse/HADOOP-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261281#comment-13261281
]
Jim Donofrio commented on HADOOP-7940:
--
This will likely hurt the performance problem described in HADOOP-6109.
I was looking at the javadoc in Hadoop 1.0.2. The more recent javadoc adds:
Please use {@link #copyBytes()} if you need the returned array to be precisely
the length of the data. which makes it even clearer than you must pay
attention to the length if you use getBytes()
method clear() in org.apache.hadoop.io.Text does not work
-
Key: HADOOP-7940
URL: https://issues.apache.org/jira/browse/HADOOP-7940
Project: Hadoop Common
Issue Type: Bug
Components: io
Affects Versions: 0.20.205.0
Environment: Ubuntu, hadoop cloudera CDH3U2, Oracle SUN JDK 6U30
Reporter: Aaron,
Assignee: Csaba Miklos
Labels: patch
Fix For: 2.0.0
Attachments: HADOOP-7940.patch
Original Estimate: 2h
Remaining Estimate: 2h
LineReader reader = new LineReader(in, 4096);
...
Text text = new Text();
while((reader.readLine(text)) 0) {
...
text.clear();
}
}
Even the clear() method is called each time, some bytes are still not filled
as zero.
So, when reader.readLine(text) is called in a loop, some bytes are dirty
which was from last call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8308) Support cross-project Jenkins builds
[ https://issues.apache.org/jira/browse/HADOOP-8308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom White updated HADOOP-8308: -- Attachment: HADOOP-8308.patch With this patch, test-patch only runs findbugs and tests for modules that have changed. I tested it with an artificial patch that had changes in various modules and verified that it ran the correct tests. Support cross-project Jenkins builds Key: HADOOP-8308 URL: https://issues.apache.org/jira/browse/HADOOP-8308 Project: Hadoop Common Issue Type: Task Components: build Reporter: Tom White Attachments: HADOOP-8308.patch This issue is to change test-patch to run only the tests for modules that have changed and then run from the top-level. See discussion at http://mail-archives.aurora.apache.org/mod_mbox/hadoop-common-dev/201204.mbox/%3ccaf-wd4tvkwypuuq9ibxv4uz8b2behxnpfkb5mq3d-pwvksh...@mail.gmail.com%3E. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HADOOP-8308) Support cross-project Jenkins builds
[ https://issues.apache.org/jira/browse/HADOOP-8308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom White reassigned HADOOP-8308: - Assignee: Tom White Support cross-project Jenkins builds Key: HADOOP-8308 URL: https://issues.apache.org/jira/browse/HADOOP-8308 Project: Hadoop Common Issue Type: Task Components: build Reporter: Tom White Assignee: Tom White Attachments: HADOOP-8308.patch This issue is to change test-patch to run only the tests for modules that have changed and then run from the top-level. See discussion at http://mail-archives.aurora.apache.org/mod_mbox/hadoop-common-dev/201204.mbox/%3ccaf-wd4tvkwypuuq9ibxv4uz8b2behxnpfkb5mq3d-pwvksh...@mail.gmail.com%3E. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
