[jira] [Updated] (HADOOP-9322) LdapGroupsMapping doesn't seem to set a timeout for its directory search
[ https://issues.apache.org/jira/browse/HADOOP-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J updated HADOOP-9322: Attachment: HADOOP-9322.patch > LdapGroupsMapping doesn't seem to set a timeout for its directory search > > > Key: HADOOP-9322 > URL: https://issues.apache.org/jira/browse/HADOOP-9322 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.0.3-alpha >Reporter: Harsh J >Priority: Minor > Labels: performance > Attachments: HADOOP-9322.patch > > > We don't appear to be setting a timeout via > http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/SearchControls.html#setTimeLimit(int) > before we search with > http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/DirContext.html#search(javax.naming.Name,%20java.lang.String,%20javax.naming.directory.SearchControls). > This may occasionally lead to some unwanted NN pauses due to lock-holding on > the operations that do group lookups. A timeout is better to define than rely > on "0" (infinite wait). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9322) LdapGroupsMapping doesn't seem to set a timeout for its directory search
[ https://issues.apache.org/jira/browse/HADOOP-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J updated HADOOP-9322: Assignee: Harsh J Status: Patch Available (was: Open) Patch that adds in a configurable time limit, with default being 10s. I'm unsure how to add in a test specifically for this, but this does just extend on the already-in-use SearchControls API, which should have test cases of its own in the Java sources. > LdapGroupsMapping doesn't seem to set a timeout for its directory search > > > Key: HADOOP-9322 > URL: https://issues.apache.org/jira/browse/HADOOP-9322 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.0.3-alpha >Reporter: Harsh J >Assignee: Harsh J >Priority: Minor > Labels: performance > Attachments: HADOOP-9322.patch > > > We don't appear to be setting a timeout via > http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/SearchControls.html#setTimeLimit(int) > before we search with > http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/DirContext.html#search(javax.naming.Name,%20java.lang.String,%20javax.naming.directory.SearchControls). > This may occasionally lead to some unwanted NN pauses due to lock-holding on > the operations that do group lookups. A timeout is better to define than rely > on "0" (infinite wait). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9322) LdapGroupsMapping doesn't seem to set a timeout for its directory search
[ https://issues.apache.org/jira/browse/HADOOP-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J updated HADOOP-9322: Target Version/s: 2.0.5-beta > LdapGroupsMapping doesn't seem to set a timeout for its directory search > > > Key: HADOOP-9322 > URL: https://issues.apache.org/jira/browse/HADOOP-9322 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.0.3-alpha >Reporter: Harsh J >Assignee: Harsh J >Priority: Minor > Labels: performance > Attachments: HADOOP-9322.patch > > > We don't appear to be setting a timeout via > http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/SearchControls.html#setTimeLimit(int) > before we search with > http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/DirContext.html#search(javax.naming.Name,%20java.lang.String,%20javax.naming.directory.SearchControls). > This may occasionally lead to some unwanted NN pauses due to lock-holding on > the operations that do group lookups. A timeout is better to define than rely > on "0" (infinite wait). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9467) Metrics2 record filtering (.record.filter.include/exclude) does not filter by name
[ https://issues.apache.org/jira/browse/HADOOP-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627607#comment-13627607 ] Hudson commented on HADOOP-9467: Integrated in Hadoop-trunk-Commit #3588 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/3588/]) HADOOP-9467. Metrics2 record filter should check name as well as tags. (Ganeshan Iyler via llu) (Revision 1466377) Result = SUCCESS llu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1466377 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/metrics2/MetricsFilter.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/metrics2/filter/TestPatternFilter.java > Metrics2 record filtering (.record.filter.include/exclude) does not filter by > name > -- > > Key: HADOOP-9467 > URL: https://issues.apache.org/jira/browse/HADOOP-9467 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 1.2.0, 3.0.0, 1-win, 2.0.4-alpha >Reporter: Chris Nauroth >Assignee: Chris Nauroth > Attachments: HADOOP-9467.1.patch, HADOOP-9467-branch-1.1.patch > > > Filtering by record considers only the record's tag for filtering and not the > record's name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9467) Metrics2 record filtering (.record.filter.include/exclude) does not filter by name
[ https://issues.apache.org/jira/browse/HADOOP-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luke Lu updated HADOOP-9467: Resolution: Fixed Fix Version/s: 2.0.4-alpha 1.2.0 Status: Resolved (was: Patch Available) > Metrics2 record filtering (.record.filter.include/exclude) does not filter by > name > -- > > Key: HADOOP-9467 > URL: https://issues.apache.org/jira/browse/HADOOP-9467 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 1.2.0, 3.0.0, 1-win, 2.0.4-alpha >Reporter: Chris Nauroth >Assignee: Chris Nauroth > Fix For: 1.2.0, 2.0.4-alpha > > Attachments: HADOOP-9467.1.patch, HADOOP-9467-branch-1.1.patch > > > Filtering by record considers only the record's tag for filtering and not the > record's name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9322) LdapGroupsMapping doesn't seem to set a timeout for its directory search
[
https://issues.apache.org/jira/browse/HADOOP-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627623#comment-13627623
]
Hadoop QA commented on HADOOP-9322:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12577971/HADOOP-9322.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2434//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2434//console
This message is automatically generated.
> LdapGroupsMapping doesn't seem to set a timeout for its directory search
>
>
> Key: HADOOP-9322
> URL: https://issues.apache.org/jira/browse/HADOOP-9322
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.0.3-alpha
>Reporter: Harsh J
>Assignee: Harsh J
>Priority: Minor
> Labels: performance
> Attachments: HADOOP-9322.patch
>
>
> We don't appear to be setting a timeout via
> http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/SearchControls.html#setTimeLimit(int)
> before we search with
> http://docs.oracle.com/javase/6/docs/api/javax/naming/directory/DirContext.html#search(javax.naming.Name,%20java.lang.String,%20javax.naming.directory.SearchControls).
> This may occasionally lead to some unwanted NN pauses due to lock-holding on
> the operations that do group lookups. A timeout is better to define than rely
> on "0" (infinite wait).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9437) TestNativeIO#testRenameTo fails on Windows due to assumption that POSIX errno is embedded in NativeIOException
[
https://issues.apache.org/jira/browse/HADOOP-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627670#comment-13627670
]
Hudson commented on HADOOP-9437:
Integrated in Hadoop-Yarn-trunk #179 (See
[https://builds.apache.org/job/Hadoop-Yarn-trunk/179/])
HADOOP-9437. TestNativeIO#testRenameTo fails on Windows due to assumption
that POSIX errno is embedded in NativeIOException. Contributed by Chris
Nauroth. (Revision 1466306)
Result = SUCCESS
suresh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1466306
Files :
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/io/nativeio/NativeIO.c
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/io/nativeio/TestNativeIO.java
> TestNativeIO#testRenameTo fails on Windows due to assumption that POSIX errno
> is embedded in NativeIOException
> --
>
> Key: HADOOP-9437
> URL: https://issues.apache.org/jira/browse/HADOOP-9437
> Project: Hadoop Common
> Issue Type: Bug
> Components: test
>Affects Versions: 3.0.0
>Reporter: Chris Nauroth
>Assignee: Chris Nauroth
> Fix For: 3.0.0
>
> Attachments: HADOOP-9437.1.patch, HADOOP-9437.2.patch,
> HADOOP-9437.3.patch
>
>
> HDFS-4428 added a detailed error message for failures to rename files by
> embedding the POSIX errno in the {{NativeIOException}}. On Windows, the
> mapping of errno is not performed, so the errno enum value will not be
> present in the {{NativeIOException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9467) Metrics2 record filtering (.record.filter.include/exclude) does not filter by name
[ https://issues.apache.org/jira/browse/HADOOP-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627674#comment-13627674 ] Hudson commented on HADOOP-9467: Integrated in Hadoop-Yarn-trunk #179 (See [https://builds.apache.org/job/Hadoop-Yarn-trunk/179/]) HADOOP-9467. Metrics2 record filter should check name as well as tags. (Ganeshan Iyler via llu) (Revision 1466377) Result = SUCCESS llu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1466377 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/metrics2/MetricsFilter.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/metrics2/filter/TestPatternFilter.java > Metrics2 record filtering (.record.filter.include/exclude) does not filter by > name > -- > > Key: HADOOP-9467 > URL: https://issues.apache.org/jira/browse/HADOOP-9467 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 1.2.0, 3.0.0, 1-win, 2.0.4-alpha >Reporter: Chris Nauroth >Assignee: Chris Nauroth > Fix For: 1.2.0, 2.0.4-alpha > > Attachments: HADOOP-9467.1.patch, HADOOP-9467-branch-1.1.patch > > > Filtering by record considers only the record's tag for filtering and not the > record's name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-7821) Hadoop event notification system
[ https://issues.apache.org/jira/browse/HADOOP-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627681#comment-13627681 ] Jyotiska NK commented on HADOOP-7821: - Hi, I am working with Ananda on this project, we have released our first patch for the Notification System which is based on ActiveMQ publish subscribe model. We will be updating the project with a detailed documentation very soon. Here is the link: https://github.com/jyotiska/pigeon > Hadoop event notification system > > > Key: HADOOP-7821 > URL: https://issues.apache.org/jira/browse/HADOOP-7821 > Project: Hadoop Common > Issue Type: New Feature >Affects Versions: 0.24.0 >Reporter: John George > > It will be good if Hadoop supports some sort of a messaging service that > allows users to subscribe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9456) Task logs are not generated for successful tasks
[ https://issues.apache.org/jira/browse/HADOOP-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627693#comment-13627693 ] chandrashekhar Kotekar commented on HADOOP-9456: Hi, I would like to solve this problem but as I am new in Hadoop development community, I do not how and where to start. I am not sure if this is the right place to ask this question. Can you please give me some pointer regarding how do people usually solve problems in this community? Generally when this kind of problem comes up, I ask for steps to re-produce this problem. How do things work in here? Thanks, Chandrashekhar > Task logs are not generated for successful tasks > > > Key: HADOOP-9456 > URL: https://issues.apache.org/jira/browse/HADOOP-9456 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 1.1.2 > Environment: 4-node linux cluster running Redhat 6.3 and Hadoop > 1.1.2.21 (from a old tarball of Hortonworks) >Reporter: Weiming Shi >Priority: Minor > > When i checked about the task logs of a complete job in the Web UI, i found > that some of the tasks logs showed up "java.lang.NoClassDefFoundError: > org/apache/hadoop/mapred/TaskLog$Reader". Checking about the log of the job > tracker confirms that those tasks have completed successfully while checking > about the log directory of that job reveals that logs of some successful > tasks are not generated. > Detailed log showed in the Web UI is attached below: > == > HTTP ERROR 500 > Problem accessing /tasklog. Reason: > org/apache/hadoop/mapred/TaskLog$Reader > Caused by: > java.lang.NoClassDefFoundError: org/apache/hadoop/mapred/TaskLog$Reader > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) > at java.lang.Class.getConstructor0(Class.java:2699) > at java.lang.Class.newInstance0(Class.java:326) > at java.lang.Class.newInstance(Class.java:308) > at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153) > at > org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:428) > at > org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221) > at > org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:881) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:326) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) > Caused by: java.lang.ClassNotFoundException: > org.apache.hadoop.mapred.TaskLog$Reader > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > ... 27 more > Caused by: > java.lang.ClassNotFoundException: org.apache.hadoop.mapred.TaskLog$Reader > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java
[jira] [Commented] (HADOOP-9437) TestNativeIO#testRenameTo fails on Windows due to assumption that POSIX errno is embedded in NativeIOException
[
https://issues.apache.org/jira/browse/HADOOP-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627759#comment-13627759
]
Hudson commented on HADOOP-9437:
Integrated in Hadoop-Hdfs-trunk #1368 (See
[https://builds.apache.org/job/Hadoop-Hdfs-trunk/1368/])
HADOOP-9437. TestNativeIO#testRenameTo fails on Windows due to assumption
that POSIX errno is embedded in NativeIOException. Contributed by Chris
Nauroth. (Revision 1466306)
Result = FAILURE
suresh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1466306
Files :
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/io/nativeio/NativeIO.c
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/io/nativeio/TestNativeIO.java
> TestNativeIO#testRenameTo fails on Windows due to assumption that POSIX errno
> is embedded in NativeIOException
> --
>
> Key: HADOOP-9437
> URL: https://issues.apache.org/jira/browse/HADOOP-9437
> Project: Hadoop Common
> Issue Type: Bug
> Components: test
>Affects Versions: 3.0.0
>Reporter: Chris Nauroth
>Assignee: Chris Nauroth
> Fix For: 3.0.0
>
> Attachments: HADOOP-9437.1.patch, HADOOP-9437.2.patch,
> HADOOP-9437.3.patch
>
>
> HDFS-4428 added a detailed error message for failures to rename files by
> embedding the POSIX errno in the {{NativeIOException}}. On Windows, the
> mapping of errno is not performed, so the errno enum value will not be
> present in the {{NativeIOException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9467) Metrics2 record filtering (.record.filter.include/exclude) does not filter by name
[ https://issues.apache.org/jira/browse/HADOOP-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627763#comment-13627763 ] Hudson commented on HADOOP-9467: Integrated in Hadoop-Hdfs-trunk #1368 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk/1368/]) HADOOP-9467. Metrics2 record filter should check name as well as tags. (Ganeshan Iyler via llu) (Revision 1466377) Result = FAILURE llu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1466377 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/metrics2/MetricsFilter.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/metrics2/filter/TestPatternFilter.java > Metrics2 record filtering (.record.filter.include/exclude) does not filter by > name > -- > > Key: HADOOP-9467 > URL: https://issues.apache.org/jira/browse/HADOOP-9467 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 1.2.0, 3.0.0, 1-win, 2.0.4-alpha >Reporter: Chris Nauroth >Assignee: Chris Nauroth > Fix For: 1.2.0, 2.0.4-alpha > > Attachments: HADOOP-9467.1.patch, HADOOP-9467-branch-1.1.patch > > > Filtering by record considers only the record's tag for filtering and not the > record's name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9437) TestNativeIO#testRenameTo fails on Windows due to assumption that POSIX errno is embedded in NativeIOException
[
https://issues.apache.org/jira/browse/HADOOP-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627814#comment-13627814
]
Hudson commented on HADOOP-9437:
Integrated in Hadoop-Mapreduce-trunk #1395 (See
[https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1395/])
HADOOP-9437. TestNativeIO#testRenameTo fails on Windows due to assumption
that POSIX errno is embedded in NativeIOException. Contributed by Chris
Nauroth. (Revision 1466306)
Result = SUCCESS
suresh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1466306
Files :
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/io/nativeio/NativeIO.c
*
/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/io/nativeio/TestNativeIO.java
> TestNativeIO#testRenameTo fails on Windows due to assumption that POSIX errno
> is embedded in NativeIOException
> --
>
> Key: HADOOP-9437
> URL: https://issues.apache.org/jira/browse/HADOOP-9437
> Project: Hadoop Common
> Issue Type: Bug
> Components: test
>Affects Versions: 3.0.0
>Reporter: Chris Nauroth
>Assignee: Chris Nauroth
> Fix For: 3.0.0
>
> Attachments: HADOOP-9437.1.patch, HADOOP-9437.2.patch,
> HADOOP-9437.3.patch
>
>
> HDFS-4428 added a detailed error message for failures to rename files by
> embedding the POSIX errno in the {{NativeIOException}}. On Windows, the
> mapping of errno is not performed, so the errno enum value will not be
> present in the {{NativeIOException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9467) Metrics2 record filtering (.record.filter.include/exclude) does not filter by name
[ https://issues.apache.org/jira/browse/HADOOP-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627818#comment-13627818 ] Hudson commented on HADOOP-9467: Integrated in Hadoop-Mapreduce-trunk #1395 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1395/]) HADOOP-9467. Metrics2 record filter should check name as well as tags. (Ganeshan Iyler via llu) (Revision 1466377) Result = SUCCESS llu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1466377 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/metrics2/MetricsFilter.java * /hadoop/common/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/metrics2/filter/TestPatternFilter.java > Metrics2 record filtering (.record.filter.include/exclude) does not filter by > name > -- > > Key: HADOOP-9467 > URL: https://issues.apache.org/jira/browse/HADOOP-9467 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 1.2.0, 3.0.0, 1-win, 2.0.4-alpha >Reporter: Chris Nauroth >Assignee: Chris Nauroth > Fix For: 1.2.0, 2.0.4-alpha > > Attachments: HADOOP-9467.1.patch, HADOOP-9467-branch-1.1.patch > > > Filtering by record considers only the record's tag for filtering and not the > record's name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9467) Metrics2 record filtering (.record.filter.include/exclude) does not filter by name
[ https://issues.apache.org/jira/browse/HADOOP-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627853#comment-13627853 ] Chris Nauroth commented on HADOOP-9467: --- Luke, thank you for the quick review and commit! > Metrics2 record filtering (.record.filter.include/exclude) does not filter by > name > -- > > Key: HADOOP-9467 > URL: https://issues.apache.org/jira/browse/HADOOP-9467 > Project: Hadoop Common > Issue Type: Bug > Components: metrics >Affects Versions: 1.2.0, 3.0.0, 1-win, 2.0.4-alpha >Reporter: Chris Nauroth >Assignee: Chris Nauroth > Fix For: 1.2.0, 2.0.4-alpha > > Attachments: HADOOP-9467.1.patch, HADOOP-9467-branch-1.1.patch > > > Filtering by record considers only the record's tag for filtering and not the > record's name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8545) Filesystem Implementation for OpenStack Swift
[
https://issues.apache.org/jira/browse/HADOOP-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran updated HADOOP-8545:
---
Attachment: HADOOP-8545-21.patch
Changes in this patch
# integration with rest of build so that the hadoop-openstack.jar and any
dependencies go into the tarball.
# GETs to find the location of files (a feature to arrive in the september
release of openstack) are off by default -the service specific
{{location-aware}} property must be true for this to work. No tests for this
other than functional tests against different Swift filesystems.
# Default block size is non-zero (tests for this), and can be overridden for
all swift filesystems with a configuration property. Comes with unit tests.
# New configuration options are documented.
> Filesystem Implementation for OpenStack Swift
> -
>
> Key: HADOOP-8545
> URL: https://issues.apache.org/jira/browse/HADOOP-8545
> Project: Hadoop Common
> Issue Type: New Feature
> Components: fs
>Affects Versions: 2.0.3-alpha, 1.1.2
>Reporter: Tim Miller
>Assignee: Dmitry Mezhensky
> Labels: hadoop, patch
> Attachments: HADOOP-8545-10.patch, HADOOP-8545-11.patch,
> HADOOP-8545-12.patch, HADOOP-8545-13.patch, HADOOP-8545-14.patch,
> HADOOP-8545-15.patch, HADOOP-8545-16.patch, HADOOP-8545-17.patch,
> HADOOP-8545-18.patch, HADOOP-8545-19.patch, HADOOP-8545-1.patch,
> HADOOP-8545-20.patch, HADOOP-8545-21.patch, HADOOP-8545-2.patch,
> HADOOP-8545-3.patch, HADOOP-8545-4.patch, HADOOP-8545-5.patch,
> HADOOP-8545-6.patch, HADOOP-8545-7.patch, HADOOP-8545-8.patch,
> HADOOP-8545-9.patch, HADOOP-8545-javaclouds-2.patch, HADOOP-8545.patch,
> HADOOP-8545.patch
>
>
> ,Add a filesystem implementation for OpenStack Swift object store, similar to
> the one which exists today for S3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8545) Filesystem Implementation for OpenStack Swift
[ https://issues.apache.org/jira/browse/HADOOP-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Loughran updated HADOOP-8545: --- Status: Patch Available (was: Open) > Filesystem Implementation for OpenStack Swift > - > > Key: HADOOP-8545 > URL: https://issues.apache.org/jira/browse/HADOOP-8545 > Project: Hadoop Common > Issue Type: New Feature > Components: fs >Affects Versions: 1.1.2, 2.0.3-alpha >Reporter: Tim Miller >Assignee: Dmitry Mezhensky > Labels: hadoop, patch > Attachments: HADOOP-8545-10.patch, HADOOP-8545-11.patch, > HADOOP-8545-12.patch, HADOOP-8545-13.patch, HADOOP-8545-14.patch, > HADOOP-8545-15.patch, HADOOP-8545-16.patch, HADOOP-8545-17.patch, > HADOOP-8545-18.patch, HADOOP-8545-19.patch, HADOOP-8545-1.patch, > HADOOP-8545-20.patch, HADOOP-8545-21.patch, HADOOP-8545-2.patch, > HADOOP-8545-3.patch, HADOOP-8545-4.patch, HADOOP-8545-5.patch, > HADOOP-8545-6.patch, HADOOP-8545-7.patch, HADOOP-8545-8.patch, > HADOOP-8545-9.patch, HADOOP-8545-javaclouds-2.patch, HADOOP-8545.patch, > HADOOP-8545.patch > > > ,Add a filesystem implementation for OpenStack Swift object store, similar to > the one which exists today for S3. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9456) Task logs are not generated for successful tasks
[ https://issues.apache.org/jira/browse/HADOOP-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627900#comment-13627900 ] Weiming Shi commented on HADOOP-9456: - Hi Chandrashekhar, i use hadoop for my own study. I am also an outsider as regard to how people usually fix the jira. But I think the way to reproduce the error is to simply run a wordcount example with the installed hadoop distribution in a true cluster mode. Thanks > Task logs are not generated for successful tasks > > > Key: HADOOP-9456 > URL: https://issues.apache.org/jira/browse/HADOOP-9456 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 1.1.2 > Environment: 4-node linux cluster running Redhat 6.3 and Hadoop > 1.1.2.21 (from a old tarball of Hortonworks) >Reporter: Weiming Shi >Priority: Minor > > When i checked about the task logs of a complete job in the Web UI, i found > that some of the tasks logs showed up "java.lang.NoClassDefFoundError: > org/apache/hadoop/mapred/TaskLog$Reader". Checking about the log of the job > tracker confirms that those tasks have completed successfully while checking > about the log directory of that job reveals that logs of some successful > tasks are not generated. > Detailed log showed in the Web UI is attached below: > == > HTTP ERROR 500 > Problem accessing /tasklog. Reason: > org/apache/hadoop/mapred/TaskLog$Reader > Caused by: > java.lang.NoClassDefFoundError: org/apache/hadoop/mapred/TaskLog$Reader > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) > at java.lang.Class.getConstructor0(Class.java:2699) > at java.lang.Class.newInstance0(Class.java:326) > at java.lang.Class.newInstance(Class.java:308) > at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153) > at > org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:428) > at > org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221) > at > org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:881) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) > at org.mortbay.jetty.Server.handle(Server.java:326) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) > at > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) > Caused by: java.lang.ClassNotFoundException: > org.apache.hadoop.mapred.TaskLog$Reader > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > ... 27 more > Caused by: > java.lang.ClassNotFoundException: org.apache.hadoop.mapred.TaskLog$Reader > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClas
[jira] [Updated] (HADOOP-9233) Cover package org.apache.hadoop.compress.zlib with unit tests
[ https://issues.apache.org/jira/browse/HADOOP-9233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lowe updated HADOOP-9233: --- Status: Patch Available (was: Open) > Cover package org.apache.hadoop.compress.zlib with unit tests > - > > Key: HADOOP-9233 > URL: https://issues.apache.org/jira/browse/HADOOP-9233 > Project: Hadoop Common > Issue Type: Test >Affects Versions: 2.0.3-alpha, 3.0.0, 0.23.6 >Reporter: Vadim Bondarev >Assignee: Vadim Bondarev > Attachments: HADOOP-9233-branch-0.23-b.patch, > HADOOP-9233-branch-2-a.patch, HADOOP-9233-branch-2-b.patch, > HADOOP-9233-trunk-a.patch, HADOOP-9233-trunk-b.patch, > HADOOP-9233-trunk-c.patch, HADOOP-9233-trunk-d.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9222) Cover package with org.apache.hadoop.io.lz4 unit tests
[ https://issues.apache.org/jira/browse/HADOOP-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lowe updated HADOOP-9222: --- Status: Patch Available (was: Open) > Cover package with org.apache.hadoop.io.lz4 unit tests > -- > > Key: HADOOP-9222 > URL: https://issues.apache.org/jira/browse/HADOOP-9222 > Project: Hadoop Common > Issue Type: Test >Affects Versions: 2.0.3-alpha, 3.0.0, 0.23.6 >Reporter: Vadim Bondarev >Assignee: Vadim Bondarev > Attachments: HADOOP-9222-branch-0.23-a.patch, > HADOOP-9222-branch-0.23-b.patch, HADOOP-9222-branch-2-a.patch, > HADOOP-9222-branch-2-b.patch, HADOOP-9222-trunk-a.patch, > HADOOP-9222-trunk-b.patch, HADOOP-9222-trunk-c.patch > > > Add test class TestLz4CompressorDecompressor with method for Lz4Compressor, > Lz4Decompressor testing -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9063) enhance unit-test coverage of class org.apache.hadoop.fs.FileUtil
[ https://issues.apache.org/jira/browse/HADOOP-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan A. Veselovsky updated HADOOP-9063: --- Attachment: HADOOP-9063-trunk--N6.patch HADOOP-9063-branch-2--N1.patch re-submitting the patches since branch-2 now needs a separate version. > enhance unit-test coverage of class org.apache.hadoop.fs.FileUtil > - > > Key: HADOOP-9063 > URL: https://issues.apache.org/jira/browse/HADOOP-9063 > Project: Hadoop Common > Issue Type: Test >Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.6 >Reporter: Ivan A. Veselovsky >Assignee: Ivan A. Veselovsky >Priority: Minor > Attachments: HADOOP-9063--b.patch, HADOOP-9063-branch-0.23--b.patch, > HADOOP-9063-branch-0.23--c.patch, HADOOP-9063-branch-2--N1.patch, > HADOOP-9063.patch, HADOOP-9063-trunk--c.patch, HADOOP-9063-trunk--c.patch, > HADOOP-9063-trunk--N2.patch, HADOOP-9063-trunk--N3.patch, > HADOOP-9063-trunk--N6.patch > > > Some methods of class org.apache.hadoop.fs.FileUtil are covered by unit-tests > poorly or not covered at all. Enhance the coverage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9291) enhance unit-test coverage of package o.a.h.metrics2
[ https://issues.apache.org/jira/browse/HADOOP-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan A. Veselovsky updated HADOOP-9291: --- Attachment: HADOOP-9291-trunk--N6.patch N6: trunk version of the patch updated because of merge over HADOOP-9467. > enhance unit-test coverage of package o.a.h.metrics2 > > > Key: HADOOP-9291 > URL: https://issues.apache.org/jira/browse/HADOOP-9291 > Project: Hadoop Common > Issue Type: Test >Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.7 >Reporter: Ivan A. Veselovsky >Assignee: Ivan A. Veselovsky > Attachments: HADOOP-9291-branch-0.23--N4.patch, > HADOOP-9291-trunk--N4.patch, HADOOP-9291-trunk--N5.patch, > HADOOP-9291-trunk--N6.patch, HADOOP-9291-trunk--N6.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8545) Filesystem Implementation for OpenStack Swift
[
https://issues.apache.org/jira/browse/HADOOP-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627928#comment-13627928
]
Hadoop QA commented on HADOOP-8545:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12578018/HADOOP-8545-21.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 23 new
or modified test files.
{color:red}-1 javac{color}. The applied patch generated 1376 javac
compiler warnings (more than the trunk's current 1367 warnings).
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common hadoop-tools/hadoop-openstack
hadoop-tools/hadoop-tools-dist.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2435//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2435//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-openstack.html
Javac warnings:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2435//artifact/trunk/patchprocess/diffJavacWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2435//console
This message is automatically generated.
> Filesystem Implementation for OpenStack Swift
> -
>
> Key: HADOOP-8545
> URL: https://issues.apache.org/jira/browse/HADOOP-8545
> Project: Hadoop Common
> Issue Type: New Feature
> Components: fs
>Affects Versions: 2.0.3-alpha, 1.1.2
>Reporter: Tim Miller
>Assignee: Dmitry Mezhensky
> Labels: hadoop, patch
> Attachments: HADOOP-8545-10.patch, HADOOP-8545-11.patch,
> HADOOP-8545-12.patch, HADOOP-8545-13.patch, HADOOP-8545-14.patch,
> HADOOP-8545-15.patch, HADOOP-8545-16.patch, HADOOP-8545-17.patch,
> HADOOP-8545-18.patch, HADOOP-8545-19.patch, HADOOP-8545-1.patch,
> HADOOP-8545-20.patch, HADOOP-8545-21.patch, HADOOP-8545-2.patch,
> HADOOP-8545-3.patch, HADOOP-8545-4.patch, HADOOP-8545-5.patch,
> HADOOP-8545-6.patch, HADOOP-8545-7.patch, HADOOP-8545-8.patch,
> HADOOP-8545-9.patch, HADOOP-8545-javaclouds-2.patch, HADOOP-8545.patch,
> HADOOP-8545.patch
>
>
> ,Add a filesystem implementation for OpenStack Swift object store, similar to
> the one which exists today for S3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9233) Cover package org.apache.hadoop.compress.zlib with unit tests
[
https://issues.apache.org/jira/browse/HADOOP-9233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627932#comment-13627932
]
Hadoop QA commented on HADOOP-9233:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12577783/HADOOP-9233-trunk-d.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2436//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2436//console
This message is automatically generated.
> Cover package org.apache.hadoop.compress.zlib with unit tests
> -
>
> Key: HADOOP-9233
> URL: https://issues.apache.org/jira/browse/HADOOP-9233
> Project: Hadoop Common
> Issue Type: Test
>Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.6
>Reporter: Vadim Bondarev
>Assignee: Vadim Bondarev
> Attachments: HADOOP-9233-branch-0.23-b.patch,
> HADOOP-9233-branch-2-a.patch, HADOOP-9233-branch-2-b.patch,
> HADOOP-9233-trunk-a.patch, HADOOP-9233-trunk-b.patch,
> HADOOP-9233-trunk-c.patch, HADOOP-9233-trunk-d.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9222) Cover package with org.apache.hadoop.io.lz4 unit tests
[
https://issues.apache.org/jira/browse/HADOOP-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627935#comment-13627935
]
Hadoop QA commented on HADOOP-9222:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12577789/HADOOP-9222-trunk-c.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2437//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2437//console
This message is automatically generated.
> Cover package with org.apache.hadoop.io.lz4 unit tests
> --
>
> Key: HADOOP-9222
> URL: https://issues.apache.org/jira/browse/HADOOP-9222
> Project: Hadoop Common
> Issue Type: Test
>Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.6
>Reporter: Vadim Bondarev
>Assignee: Vadim Bondarev
> Attachments: HADOOP-9222-branch-0.23-a.patch,
> HADOOP-9222-branch-0.23-b.patch, HADOOP-9222-branch-2-a.patch,
> HADOOP-9222-branch-2-b.patch, HADOOP-9222-trunk-a.patch,
> HADOOP-9222-trunk-b.patch, HADOOP-9222-trunk-c.patch
>
>
> Add test class TestLz4CompressorDecompressor with method for Lz4Compressor,
> Lz4Decompressor testing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8943) Support multiple group mapping providers
[ https://issues.apache.org/jira/browse/HADOOP-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627939#comment-13627939 ] Andrew Perepelytsya commented on HADOOP-8943: - Hi, any action on this patch? All checkpoints green. This is the major step in supporting access control lists on Hadoop. > Support multiple group mapping providers > > > Key: HADOOP-8943 > URL: https://issues.apache.org/jira/browse/HADOOP-8943 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Reporter: Kai Zheng > Fix For: 2.0.5-beta > > Attachments: HADOOP-8943.patch, HADOOP-8943.patch, HADOOP-8943.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > Discussed with Natty about LdapGroupMapping, we need to improve it so that: > 1. It's possible to do different group mapping for different > users/principals. For example, AD user should go to LdapGroupMapping service > for group, but service principals such as hdfs, mapred can still use the > default one ShellBasedUnixGroupsMapping; > 2. Multiple ADs can be supported to do LdapGroupMapping; > 3. It's possible to configure what kind of users/principals (regarding > domain/realm is an option) should use which group mapping service/mechanism. > 4. It's possible to configure and combine multiple existing mapping providers > without writing codes implementing new one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9291) enhance unit-test coverage of package o.a.h.metrics2
[
https://issues.apache.org/jira/browse/HADOOP-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627956#comment-13627956
]
Hadoop QA commented on HADOOP-9291:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12578024/HADOOP-9291-trunk--N6.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2438//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2438//console
This message is automatically generated.
> enhance unit-test coverage of package o.a.h.metrics2
>
>
> Key: HADOOP-9291
> URL: https://issues.apache.org/jira/browse/HADOOP-9291
> Project: Hadoop Common
> Issue Type: Test
>Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.7
>Reporter: Ivan A. Veselovsky
>Assignee: Ivan A. Veselovsky
> Attachments: HADOOP-9291-branch-0.23--N4.patch,
> HADOOP-9291-trunk--N4.patch, HADOOP-9291-trunk--N5.patch,
> HADOOP-9291-trunk--N6.patch, HADOOP-9291-trunk--N6.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9063) enhance unit-test coverage of class org.apache.hadoop.fs.FileUtil
[
https://issues.apache.org/jira/browse/HADOOP-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627969#comment-13627969
]
Hadoop QA commented on HADOOP-9063:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12578023/HADOOP-9063-trunk--N6.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-common-project/hadoop-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2439//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2439//console
This message is automatically generated.
> enhance unit-test coverage of class org.apache.hadoop.fs.FileUtil
> -
>
> Key: HADOOP-9063
> URL: https://issues.apache.org/jira/browse/HADOOP-9063
> Project: Hadoop Common
> Issue Type: Test
>Affects Versions: 3.0.0, 2.0.3-alpha, 0.23.6
>Reporter: Ivan A. Veselovsky
>Assignee: Ivan A. Veselovsky
>Priority: Minor
> Attachments: HADOOP-9063--b.patch, HADOOP-9063-branch-0.23--b.patch,
> HADOOP-9063-branch-0.23--c.patch, HADOOP-9063-branch-2--N1.patch,
> HADOOP-9063.patch, HADOOP-9063-trunk--c.patch, HADOOP-9063-trunk--c.patch,
> HADOOP-9063-trunk--N2.patch, HADOOP-9063-trunk--N3.patch,
> HADOOP-9063-trunk--N6.patch
>
>
> Some methods of class org.apache.hadoop.fs.FileUtil are covered by unit-tests
> poorly or not covered at all. Enhance the coverage.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9468) JVM path embedded in fuse binaries
Sean Mackrory created HADOOP-9468: - Summary: JVM path embedded in fuse binaries Key: HADOOP-9468 URL: https://issues.apache.org/jira/browse/HADOOP-9468 Project: Hadoop Common Issue Type: Bug Reporter: Sean Mackrory Assignee: Sean Mackrory When the FUSE binaries are built, the paths to libraries in the JVMs is embedded in the RPATH so that they can be found at run-time. From an Apache Bigtop perspective, this is not sufficient because the software may be run on a machine configured very differently from the one on which they were built - so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an issue where the original JVM path existed, causing LD_LIBRARY_PATH to be ignored in favor of the RPATH, but it was not the JVM intended for running Hadoop (not JAVA_HOME), and this caused problems. I'm told that setting LD_LIBRARY_PATH is standard practice before using the fuse program anyway, and if that's the case, I think removing the RPATH from the binaries is a good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9371) Define Semantics of FileSystem and FileContext more rigorously
[
https://issues.apache.org/jira/browse/HADOOP-9371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628045#comment-13628045
]
Steve Loughran commented on HADOOP-9371:
bradley -thanks for your research.
I wonder if we should just say, in the concurrency section:
* Multiple writers MAY open a file for writing. If this occurs, the outcome is
undefined
I guess we have to make sure that Syncable is defined here too
> Define Semantics of FileSystem and FileContext more rigorously
> --
>
> Key: HADOOP-9371
> URL: https://issues.apache.org/jira/browse/HADOOP-9371
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs
>Affects Versions: 1.2.0, 3.0.0
>Reporter: Steve Loughran
>Assignee: Steve Loughran
> Attachments: HADOOP-9361.2.patch, HADOOP-9361.patch,
> HadoopFilesystemContract.pdf
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> The semantics of {{FileSystem}} and {{FileContext}} are not completely
> defined in terms of
> # core expectations of a filesystem
> # consistency requirements.
> # concurrency requirements.
> # minimum scale limits
> Furthermore, methods are not defined strictly enough in terms of their
> outcomes and failure modes.
> The requirements and method semantics should be defined more strictly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9468) JVM path embedded in fuse binaries
[ https://issues.apache.org/jira/browse/HADOOP-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Mackrory updated HADOOP-9468: -- Attachment: 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch > JVM path embedded in fuse binaries > -- > > Key: HADOOP-9468 > URL: https://issues.apache.org/jira/browse/HADOOP-9468 > Project: Hadoop Common > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory > Attachments: > 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch > > > When the FUSE binaries are built, the paths to libraries in the JVMs is > embedded in the RPATH so that they can be found at run-time. From an Apache > Bigtop perspective, this is not sufficient because the software may be run on > a machine configured very differently from the one on which they were built - > so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an > issue where the original JVM path existed, causing LD_LIBRARY_PATH to be > ignored in favor of the RPATH, but it was not the JVM intended for running > Hadoop (not JAVA_HOME), and this caused problems. > I'm told that setting LD_LIBRARY_PATH is standard practice before using the > fuse program anyway, and if that's the case, I think removing the RPATH from > the binaries is a good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9468) JVM path embedded in fuse binaries
[ https://issues.apache.org/jira/browse/HADOOP-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Mackrory updated HADOOP-9468: -- Status: Patch Available (was: Open) > JVM path embedded in fuse binaries > -- > > Key: HADOOP-9468 > URL: https://issues.apache.org/jira/browse/HADOOP-9468 > Project: Hadoop Common > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory > Attachments: > 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch > > > When the FUSE binaries are built, the paths to libraries in the JVMs is > embedded in the RPATH so that they can be found at run-time. From an Apache > Bigtop perspective, this is not sufficient because the software may be run on > a machine configured very differently from the one on which they were built - > so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an > issue where the original JVM path existed, causing LD_LIBRARY_PATH to be > ignored in favor of the RPATH, but it was not the JVM intended for running > Hadoop (not JAVA_HOME), and this caused problems. > I'm told that setting LD_LIBRARY_PATH is standard practice before using the > fuse program anyway, and if that's the case, I think removing the RPATH from > the binaries is a good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Moved] (HADOOP-9469) mapreduce/yarn source jars not included in dist tarball
[ https://issues.apache.org/jira/browse/HADOOP-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Parker moved MAPREDUCE-3707 to HADOOP-9469: -- Component/s: (was: mrv2) Target Version/s: 3.0.0, 0.23.7, 2.0.5-beta (was: 0.23.3, 2.0.0-alpha, 3.0.0) Affects Version/s: (was: 0.23.0) 0.23.0 Key: HADOOP-9469 (was: MAPREDUCE-3707) Project: Hadoop Common (was: Hadoop Map/Reduce) > mapreduce/yarn source jars not included in dist tarball > --- > > Key: HADOOP-9469 > URL: https://issues.apache.org/jira/browse/HADOOP-9469 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Thomas Graves > > the mapreduce and yarn sources jars don't get included into the distribution > tarball. It seems they get built by default just aren't assembled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9469) mapreduce/yarn source jars not included in dist tarball
[ https://issues.apache.org/jira/browse/HADOOP-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Parker updated HADOOP-9469: -- Assignee: Robert Parker > mapreduce/yarn source jars not included in dist tarball > --- > > Key: HADOOP-9469 > URL: https://issues.apache.org/jira/browse/HADOOP-9469 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Thomas Graves >Assignee: Robert Parker > > the mapreduce and yarn sources jars don't get included into the distribution > tarball. It seems they get built by default just aren't assembled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9470) eliminate duplicate FQN tests in different Hadoop modules
Ivan A. Veselovsky created HADOOP-9470: -- Summary: eliminate duplicate FQN tests in different Hadoop modules Key: HADOOP-9470 URL: https://issues.apache.org/jira/browse/HADOOP-9470 Project: Hadoop Common Issue Type: Improvement Reporter: Ivan A. Veselovsky Assignee: Ivan A. Veselovsky In different modules of Hadoop project there are tests with identical FQNs (fully qualified name). For example, test with FQN org.apache.hadoop.util.TestRunJar is contained in 2 modules: ./hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/util/TestRunJar.java ./hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/util/TestRunJar.java Such situation causes certain problems with test result reporting and other code analysis tools (such as Clover, e.g.) because almost all the tools identify the tests by their Java FQN. So, I suggest to rename all such test classes to avoid duplicate FQNs in different modules. I'm attaching simple shell script that can find all such problematic test classes. Currently Hadoop trunk has 9 such test classes, they are: $ ~/bin/find-duplicate-fqns.sh # Module [./hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/target/test-classes] has 7 duplicate FQN tests: org.apache.hadoop.ipc.TestSocketFactory org.apache.hadoop.mapred.TestFileOutputCommitter org.apache.hadoop.mapred.TestJobClient org.apache.hadoop.mapred.TestJobConf org.apache.hadoop.mapreduce.lib.output.TestFileOutputCommitter org.apache.hadoop.util.TestReflectionUtils org.apache.hadoop.util.TestRunJar # Module [./hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common/target/test-classes] has 2 duplicate FQN tests: org.apache.hadoop.yarn.TestRecordFactory org.apache.hadoop.yarn.TestRPCFactories -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9470) eliminate duplicate FQN tests in different Hadoop modules
[ https://issues.apache.org/jira/browse/HADOOP-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan A. Veselovsky updated HADOOP-9470: --- Attachment: find-duplicate-fqns.sh > eliminate duplicate FQN tests in different Hadoop modules > - > > Key: HADOOP-9470 > URL: https://issues.apache.org/jira/browse/HADOOP-9470 > Project: Hadoop Common > Issue Type: Improvement >Reporter: Ivan A. Veselovsky >Assignee: Ivan A. Veselovsky > Attachments: find-duplicate-fqns.sh > > > In different modules of Hadoop project there are tests with identical FQNs > (fully qualified name). > For example, test with FQN org.apache.hadoop.util.TestRunJar is contained in > 2 modules: > > ./hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/util/TestRunJar.java > > ./hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/util/TestRunJar.java > > Such situation causes certain problems with test result reporting and other > code analysis tools (such as Clover, e.g.) because almost all the tools > identify the tests by their Java FQN. > So, I suggest to rename all such test classes to avoid duplicate FQNs in > different modules. I'm attaching simple shell script that can find all such > problematic test classes. Currently Hadoop trunk has 9 such test classes, > they are: > $ ~/bin/find-duplicate-fqns.sh > # Module > [./hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/target/test-classes] > has 7 duplicate FQN tests: > org.apache.hadoop.ipc.TestSocketFactory > org.apache.hadoop.mapred.TestFileOutputCommitter > org.apache.hadoop.mapred.TestJobClient > org.apache.hadoop.mapred.TestJobConf > org.apache.hadoop.mapreduce.lib.output.TestFileOutputCommitter > org.apache.hadoop.util.TestReflectionUtils > org.apache.hadoop.util.TestRunJar > # Module > [./hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common/target/test-classes] > has 2 duplicate FQN tests: > org.apache.hadoop.yarn.TestRecordFactory > org.apache.hadoop.yarn.TestRPCFactories -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9470) eliminate duplicate FQN tests in different Hadoop modules
[ https://issues.apache.org/jira/browse/HADOOP-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan A. Veselovsky updated HADOOP-9470: --- Attachment: HADOOP-9470-trunk.patch Attaching atch for trunk. Only test renames are there, no other changes. > eliminate duplicate FQN tests in different Hadoop modules > - > > Key: HADOOP-9470 > URL: https://issues.apache.org/jira/browse/HADOOP-9470 > Project: Hadoop Common > Issue Type: Improvement >Reporter: Ivan A. Veselovsky >Assignee: Ivan A. Veselovsky > Attachments: find-duplicate-fqns.sh, HADOOP-9470-trunk.patch > > > In different modules of Hadoop project there are tests with identical FQNs > (fully qualified name). > For example, test with FQN org.apache.hadoop.util.TestRunJar is contained in > 2 modules: > > ./hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/util/TestRunJar.java > > ./hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/util/TestRunJar.java > > Such situation causes certain problems with test result reporting and other > code analysis tools (such as Clover, e.g.) because almost all the tools > identify the tests by their Java FQN. > So, I suggest to rename all such test classes to avoid duplicate FQNs in > different modules. I'm attaching simple shell script that can find all such > problematic test classes. Currently Hadoop trunk has 9 such test classes, > they are: > $ ~/bin/find-duplicate-fqns.sh > # Module > [./hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/target/test-classes] > has 7 duplicate FQN tests: > org.apache.hadoop.ipc.TestSocketFactory > org.apache.hadoop.mapred.TestFileOutputCommitter > org.apache.hadoop.mapred.TestJobClient > org.apache.hadoop.mapred.TestJobConf > org.apache.hadoop.mapreduce.lib.output.TestFileOutputCommitter > org.apache.hadoop.util.TestReflectionUtils > org.apache.hadoop.util.TestRunJar > # Module > [./hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common/target/test-classes] > has 2 duplicate FQN tests: > org.apache.hadoop.yarn.TestRecordFactory > org.apache.hadoop.yarn.TestRPCFactories -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9470) eliminate duplicate FQN tests in different Hadoop modules
[ https://issues.apache.org/jira/browse/HADOOP-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan A. Veselovsky updated HADOOP-9470: --- Affects Version/s: 2.0.4-alpha 0.23.7 3.0.0 > eliminate duplicate FQN tests in different Hadoop modules > - > > Key: HADOOP-9470 > URL: https://issues.apache.org/jira/browse/HADOOP-9470 > Project: Hadoop Common > Issue Type: Improvement >Affects Versions: 3.0.0, 0.23.7, 2.0.4-alpha >Reporter: Ivan A. Veselovsky >Assignee: Ivan A. Veselovsky > Attachments: find-duplicate-fqns.sh, HADOOP-9470-trunk.patch > > > In different modules of Hadoop project there are tests with identical FQNs > (fully qualified name). > For example, test with FQN org.apache.hadoop.util.TestRunJar is contained in > 2 modules: > > ./hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/util/TestRunJar.java > > ./hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/util/TestRunJar.java > > Such situation causes certain problems with test result reporting and other > code analysis tools (such as Clover, e.g.) because almost all the tools > identify the tests by their Java FQN. > So, I suggest to rename all such test classes to avoid duplicate FQNs in > different modules. I'm attaching simple shell script that can find all such > problematic test classes. Currently Hadoop trunk has 9 such test classes, > they are: > $ ~/bin/find-duplicate-fqns.sh > # Module > [./hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/target/test-classes] > has 7 duplicate FQN tests: > org.apache.hadoop.ipc.TestSocketFactory > org.apache.hadoop.mapred.TestFileOutputCommitter > org.apache.hadoop.mapred.TestJobClient > org.apache.hadoop.mapred.TestJobConf > org.apache.hadoop.mapreduce.lib.output.TestFileOutputCommitter > org.apache.hadoop.util.TestReflectionUtils > org.apache.hadoop.util.TestRunJar > # Module > [./hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common/target/test-classes] > has 2 duplicate FQN tests: > org.apache.hadoop.yarn.TestRecordFactory > org.apache.hadoop.yarn.TestRPCFactories -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9468) JVM path embedded in fuse binaries
[
https://issues.apache.org/jira/browse/HADOOP-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628164#comment-13628164
]
Hadoop QA commented on HADOOP-9468:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12578044/0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-hdfs-project/hadoop-hdfs.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2440//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2440//console
This message is automatically generated.
> JVM path embedded in fuse binaries
> --
>
> Key: HADOOP-9468
> URL: https://issues.apache.org/jira/browse/HADOOP-9468
> Project: Hadoop Common
> Issue Type: Bug
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
> Attachments:
> 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch
>
>
> When the FUSE binaries are built, the paths to libraries in the JVMs is
> embedded in the RPATH so that they can be found at run-time. From an Apache
> Bigtop perspective, this is not sufficient because the software may be run on
> a machine configured very differently from the one on which they were built -
> so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an
> issue where the original JVM path existed, causing LD_LIBRARY_PATH to be
> ignored in favor of the RPATH, but it was not the JVM intended for running
> Hadoop (not JAVA_HOME), and this caused problems.
> I'm told that setting LD_LIBRARY_PATH is standard practice before using the
> fuse program anyway, and if that's the case, I think removing the RPATH from
> the binaries is a good idea.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9455) HADOOP_CLIENT_OPTS is appended twice, causing JVM failures
[
https://issues.apache.org/jira/browse/HADOOP-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628194#comment-13628194
]
Chris Nauroth commented on HADOOP-9455:
---
Eli, thank you for taking a look.
{quote}
Wouldn't it be better to only append HADOOP_CLIENT_OPTS once in hadoop-env.sh
rather than in each per-project bin script?
{quote}
This would cause a subtle change in behavior. Right now, the hdfs script only
appends HADOOP_CLIENT_OPTS for a subset of the interactive commands: dfs,
dfsadmin, haadmin, and fsck. This is not done for the daemon commands:
namenode, datanode, secondarynamenode, etc. It appears that the intent is that
when you want to override options to a daemon, you use the daemon-specific
environment variable instead: HADOOP_NAMENODE_OPTS, HADOOP_DATANODE_OPTS,
HADOOP_SECONDARYNAMENODE_OPTS, etc. It could be erroneous to combine options
set in HADOOP_CLIENT_OPTS with options set for a daemon. For example, I could
imagine an operator wanting to maintain a single hadoop-env.sh that sets both
HADOOP_NAMENODE_OPTS and HADOOP_CLIENT_OPTS, but set different values for max
heap size within each one.
> HADOOP_CLIENT_OPTS is appended twice, causing JVM failures
> --
>
> Key: HADOOP-9455
> URL: https://issues.apache.org/jira/browse/HADOOP-9455
> Project: Hadoop Common
> Issue Type: Bug
> Components: bin
>Affects Versions: 3.0.0, 2.0.3-alpha
>Reporter: Sangjin Lee
>Assignee: Chris Nauroth
>Priority: Minor
> Attachments: HADOOP-9455.1.patch
>
>
> If you set HADOOP_CLIENT_OPTS and run hadoop, you'll find that the
> HADOOP_CLIENT_OPTS value gets appended twice, and leads to JVM start failures
> for cases like adding debug flags.
> For example,
> {noformat}
> HADOOP_CLIENT_OPTS='-agentlib:jdwp=transport=dt_socket,address=localhost:9009,server=y,suspend=y'
> hadoop jar anything
> ERROR: Cannot load this JVM TI agent twice, check your java command line for
> duplicate jdwp options.
> Error occurred during initialization of VM
> agent library failed to init: jdwp
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9469) mapreduce/yarn source jars not included in dist tarball
[ https://issues.apache.org/jira/browse/HADOOP-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Parker updated HADOOP-9469: -- Attachment: HADOOP-9469.patch After change: tar tvf ./hadoop-dist/target/hadoop-3.0.0-SNAPSHOT.tar.gz | grep sources.jar -rw-r--r-- 0 rparker staff 361204 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-api-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 18468 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-applications-distributedshell-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff4148 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-applications-distributedshell-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff5815 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-applications-unmanaged-am-launcher-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff3839 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-applications-unmanaged-am-launcher-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 23560 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-client-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 12185 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-client-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 511146 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-common-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 77299 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-common-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 54051 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-common-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff7737 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-common-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 246997 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-nodemanager-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 135604 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-nodemanager-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 334917 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-resourcemanager-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 192273 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-resourcemanager-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 17612 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-tests-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 17281 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-web-proxy-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff4916 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/yarn/sources/hadoop-yarn-server-web-proxy-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 227933 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-common-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 23255 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-common-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 947984 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-core-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 55819 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-core-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 71566 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-hs-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 61378 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-hs-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 19997 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-jobclient-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 84 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-jobclient-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 10309 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-shuffle-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff4026 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-client-shuffle-3.0.0-SNAPSHOT-test-sources.jar -rw-r--r-- 0 rparker staff 696883 Apr 10 15:18 hadoop-3.0.0-SNAPSHOT/share/hadoop/mapreduce/sources/hadoop-mapreduce-examples-3.0.0-SNAPSHOT-sources.jar -rw-r--r-- 0 rparker staff 12968 Apr 10 15:18 had
[jira] [Updated] (HADOOP-9469) mapreduce/yarn source jars not included in dist tarball
[ https://issues.apache.org/jira/browse/HADOOP-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Parker updated HADOOP-9469: -- Status: Patch Available (was: Open) > mapreduce/yarn source jars not included in dist tarball > --- > > Key: HADOOP-9469 > URL: https://issues.apache.org/jira/browse/HADOOP-9469 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 0.23.0 >Reporter: Thomas Graves >Assignee: Robert Parker > Attachments: HADOOP-9469.patch > > > the mapreduce and yarn sources jars don't get included into the distribution > tarball. It seems they get built by default just aren't assembled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9468) JVM path embedded in fuse binaries
[ https://issues.apache.org/jira/browse/HADOOP-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628208#comment-13628208 ] Colin Patrick McCabe commented on HADOOP-9468: -- looks reasonable to me. have you tested on RHEL5? > JVM path embedded in fuse binaries > -- > > Key: HADOOP-9468 > URL: https://issues.apache.org/jira/browse/HADOOP-9468 > Project: Hadoop Common > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory > Attachments: > 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch > > > When the FUSE binaries are built, the paths to libraries in the JVMs is > embedded in the RPATH so that they can be found at run-time. From an Apache > Bigtop perspective, this is not sufficient because the software may be run on > a machine configured very differently from the one on which they were built - > so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an > issue where the original JVM path existed, causing LD_LIBRARY_PATH to be > ignored in favor of the RPATH, but it was not the JVM intended for running > Hadoop (not JAVA_HOME), and this caused problems. > I'm told that setting LD_LIBRARY_PATH is standard practice before using the > fuse program anyway, and if that's the case, I think removing the RPATH from > the binaries is a good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9469) mapreduce/yarn source jars not included in dist tarball
[
https://issues.apache.org/jira/browse/HADOOP-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628220#comment-13628220
]
Hadoop QA commented on HADOOP-9469:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12578072/HADOOP-9469.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-assemblies.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2441//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2441//console
This message is automatically generated.
> mapreduce/yarn source jars not included in dist tarball
> ---
>
> Key: HADOOP-9469
> URL: https://issues.apache.org/jira/browse/HADOOP-9469
> Project: Hadoop Common
> Issue Type: Bug
>Affects Versions: 0.23.0
>Reporter: Thomas Graves
>Assignee: Robert Parker
> Attachments: HADOOP-9469.patch
>
>
> the mapreduce and yarn sources jars don't get included into the distribution
> tarball. It seems they get built by default just aren't assembled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9468) JVM path embedded in fuse binaries
[ https://issues.apache.org/jira/browse/HADOOP-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628223#comment-13628223 ] Sean Mackrory commented on HADOOP-9468: --- No - RHEL 6 only, but I've tested this change in another CMake project on RHEL 5 (among others) before. Is there a specific problem you might expect on RHEL 5 or something? > JVM path embedded in fuse binaries > -- > > Key: HADOOP-9468 > URL: https://issues.apache.org/jira/browse/HADOOP-9468 > Project: Hadoop Common > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory > Attachments: > 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch > > > When the FUSE binaries are built, the paths to libraries in the JVMs is > embedded in the RPATH so that they can be found at run-time. From an Apache > Bigtop perspective, this is not sufficient because the software may be run on > a machine configured very differently from the one on which they were built - > so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an > issue where the original JVM path existed, causing LD_LIBRARY_PATH to be > ignored in favor of the RPATH, but it was not the JVM intended for running > Hadoop (not JAVA_HOME), and this caused problems. > I'm told that setting LD_LIBRARY_PATH is standard practice before using the > fuse program anyway, and if that's the case, I think removing the RPATH from > the binaries is a good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9468) JVM path embedded in fuse binaries
[ https://issues.apache.org/jira/browse/HADOOP-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628233#comment-13628233 ] Colin Patrick McCabe commented on HADOOP-9468: -- that's probably fine, then. > JVM path embedded in fuse binaries > -- > > Key: HADOOP-9468 > URL: https://issues.apache.org/jira/browse/HADOOP-9468 > Project: Hadoop Common > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory > Attachments: > 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch > > > When the FUSE binaries are built, the paths to libraries in the JVMs is > embedded in the RPATH so that they can be found at run-time. From an Apache > Bigtop perspective, this is not sufficient because the software may be run on > a machine configured very differently from the one on which they were built - > so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an > issue where the original JVM path existed, causing LD_LIBRARY_PATH to be > ignored in favor of the RPATH, but it was not the JVM intended for running > Hadoop (not JAVA_HOME), and this caused problems. > I'm told that setting LD_LIBRARY_PATH is standard practice before using the > fuse program anyway, and if that's the case, I think removing the RPATH from > the binaries is a good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9468) JVM path embedded in fuse binaries
[ https://issues.apache.org/jira/browse/HADOOP-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628257#comment-13628257 ] Sean Mackrory commented on HADOOP-9468: --- Just tested on a RHEL 5 cluster - no problem. > JVM path embedded in fuse binaries > -- > > Key: HADOOP-9468 > URL: https://issues.apache.org/jira/browse/HADOOP-9468 > Project: Hadoop Common > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory > Attachments: > 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch > > > When the FUSE binaries are built, the paths to libraries in the JVMs is > embedded in the RPATH so that they can be found at run-time. From an Apache > Bigtop perspective, this is not sufficient because the software may be run on > a machine configured very differently from the one on which they were built - > so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an > issue where the original JVM path existed, causing LD_LIBRARY_PATH to be > ignored in favor of the RPATH, but it was not the JVM intended for running > Hadoop (not JAVA_HOME), and this caused problems. > I'm told that setting LD_LIBRARY_PATH is standard practice before using the > fuse program anyway, and if that's the case, I think removing the RPATH from > the binaries is a good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9468) JVM path embedded in fuse binaries
[ https://issues.apache.org/jira/browse/HADOOP-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628302#comment-13628302 ] Sean Mackrory commented on HADOOP-9468: --- Also works on Ubuntu 10.04, FWIW > JVM path embedded in fuse binaries > -- > > Key: HADOOP-9468 > URL: https://issues.apache.org/jira/browse/HADOOP-9468 > Project: Hadoop Common > Issue Type: Bug >Reporter: Sean Mackrory >Assignee: Sean Mackrory > Attachments: > 0001-HADOOP-9468.-Not-embedding-JVM-library-paths-in-FUSE.patch > > > When the FUSE binaries are built, the paths to libraries in the JVMs is > embedded in the RPATH so that they can be found at run-time. From an Apache > Bigtop perspective, this is not sufficient because the software may be run on > a machine configured very differently from the one on which they were built - > so a wrapper sets LD_LIBRARY_PATH according to JAVA_HOME. I recently saw an > issue where the original JVM path existed, causing LD_LIBRARY_PATH to be > ignored in favor of the RPATH, but it was not the JVM intended for running > Hadoop (not JAVA_HOME), and this caused problems. > I'm told that setting LD_LIBRARY_PATH is standard practice before using the > fuse program anyway, and if that's the case, I think removing the RPATH from > the binaries is a good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-8731) TestTrackerDistributedCacheManager fails on Windows
[ https://issues.apache.org/jira/browse/HADOOP-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628313#comment-13628313 ] Vinod Kumar Vavilapalli commented on HADOOP-8731: - The latest patch looks good, Ivan. Thanks for addressing my comments. Running the test on branch-1-win and checking this in. > TestTrackerDistributedCacheManager fails on Windows > --- > > Key: HADOOP-8731 > URL: https://issues.apache.org/jira/browse/HADOOP-8731 > Project: Hadoop Common > Issue Type: Bug > Components: filecache >Reporter: Ivan Mitic >Assignee: Ivan Mitic > Attachments: HADOOP-8731-PublicCache.2.patch, > HADOOP-8731-PublicCache.patch > > > Jira tracking TestTrackerDistributedCacheManager test failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-8731) TestTrackerDistributedCacheManager fails on Windows
[ https://issues.apache.org/jira/browse/HADOOP-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kumar Vavilapalli updated HADOOP-8731: Resolution: Fixed Fix Version/s: 1-win Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) I just committed this to branch-1-win. Thanks Ivan! > TestTrackerDistributedCacheManager fails on Windows > --- > > Key: HADOOP-8731 > URL: https://issues.apache.org/jira/browse/HADOOP-8731 > Project: Hadoop Common > Issue Type: Bug > Components: filecache >Reporter: Ivan Mitic >Assignee: Ivan Mitic > Fix For: 1-win > > Attachments: HADOOP-8731-PublicCache.2.patch, > HADOOP-8731-PublicCache.patch > > > Jira tracking TestTrackerDistributedCacheManager test failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9471) hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
Alejandro Abdelnur created HADOOP-9471:
--
Summary: hadoop-client wrongfully excludes jetty-util JAR,
breaking webhdfs
Key: HADOOP-9471
URL: https://issues.apache.org/jira/browse/HADOOP-9471
Project: Hadoop Common
Issue Type: Bug
Components: build
Affects Versions: 2.0.3-alpha
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
Fix For: 2.0.4-alpha
WebHdfsFileSystem uses jetty-util's JSON class.
hadoop-client excludes that JAR, applications built using hadoop-client POM
fail:
{code}java.lang.NoClassDefFoundError: org/mortbay/util/ajax/JSON
at
org.apache.hadoop.hdfs.web.WebHdfsFileSystem.jsonParse(WebHdfsFileSystem.java:277)
at
org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.getResponse(WebHdfsFileSystem.java:561)
at
org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.run(WebHdfsFileSystem.java:480)
at
org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:413)
at
org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHdfsFileStatus(WebHdfsFileSystem.java:580)
at
org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getFileStatus(WebHdfsFileSystem.java:591)
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1332)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9471) hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
[
https://issues.apache.org/jira/browse/HADOOP-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated HADOOP-9471:
---
Attachment: HADOOP-9471.patch
patch that removes the exclusion from hadoop-client's hadoop-hdfs dependency,
verified with a simple program that uses webhdfs:// to access HDFS and has the
hadoop-client JARs in the classpath.
> hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
> --
>
> Key: HADOOP-9471
> URL: https://issues.apache.org/jira/browse/HADOOP-9471
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.3-alpha
>Reporter: Alejandro Abdelnur
>Assignee: Alejandro Abdelnur
> Fix For: 2.0.4-alpha
>
> Attachments: HADOOP-9471.patch
>
>
> WebHdfsFileSystem uses jetty-util's JSON class.
> hadoop-client excludes that JAR, applications built using hadoop-client POM
> fail:
> {code}java.lang.NoClassDefFoundError: org/mortbay/util/ajax/JSON
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.jsonParse(WebHdfsFileSystem.java:277)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.getResponse(WebHdfsFileSystem.java:561)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.run(WebHdfsFileSystem.java:480)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:413)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHdfsFileStatus(WebHdfsFileSystem.java:580)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getFileStatus(WebHdfsFileSystem.java:591)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1332)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9471) hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
[
https://issues.apache.org/jira/browse/HADOOP-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated HADOOP-9471:
---
Status: Patch Available (was: Open)
> hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
> --
>
> Key: HADOOP-9471
> URL: https://issues.apache.org/jira/browse/HADOOP-9471
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.3-alpha
>Reporter: Alejandro Abdelnur
>Assignee: Alejandro Abdelnur
> Fix For: 2.0.4-alpha
>
> Attachments: HADOOP-9471.patch
>
>
> WebHdfsFileSystem uses jetty-util's JSON class.
> hadoop-client excludes that JAR, applications built using hadoop-client POM
> fail:
> {code}java.lang.NoClassDefFoundError: org/mortbay/util/ajax/JSON
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.jsonParse(WebHdfsFileSystem.java:277)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.getResponse(WebHdfsFileSystem.java:561)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.run(WebHdfsFileSystem.java:480)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:413)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHdfsFileStatus(WebHdfsFileSystem.java:580)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getFileStatus(WebHdfsFileSystem.java:591)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1332)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9471) hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
[
https://issues.apache.org/jira/browse/HADOOP-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628415#comment-13628415
]
Hadoop QA commented on HADOOP-9471:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12578103/HADOOP-9471.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-client.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2442//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/2442//console
This message is automatically generated.
> hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
> --
>
> Key: HADOOP-9471
> URL: https://issues.apache.org/jira/browse/HADOOP-9471
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.3-alpha
>Reporter: Alejandro Abdelnur
>Assignee: Alejandro Abdelnur
> Fix For: 2.0.4-alpha
>
> Attachments: HADOOP-9471.patch
>
>
> WebHdfsFileSystem uses jetty-util's JSON class.
> hadoop-client excludes that JAR, applications built using hadoop-client POM
> fail:
> {code}java.lang.NoClassDefFoundError: org/mortbay/util/ajax/JSON
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.jsonParse(WebHdfsFileSystem.java:277)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.getResponse(WebHdfsFileSystem.java:561)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.run(WebHdfsFileSystem.java:480)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:413)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHdfsFileStatus(WebHdfsFileSystem.java:580)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getFileStatus(WebHdfsFileSystem.java:591)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1332)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9471) hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
[
https://issues.apache.org/jira/browse/HADOOP-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628647#comment-13628647
]
Harsh J commented on HADOOP-9471:
-
Good catch (when using a WebHdfsFileSystem at the client-side). +1 on the patch.
> hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
> --
>
> Key: HADOOP-9471
> URL: https://issues.apache.org/jira/browse/HADOOP-9471
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.3-alpha
>Reporter: Alejandro Abdelnur
>Assignee: Alejandro Abdelnur
> Fix For: 2.0.4-alpha
>
> Attachments: HADOOP-9471.patch
>
>
> WebHdfsFileSystem uses jetty-util's JSON class.
> hadoop-client excludes that JAR, applications built using hadoop-client POM
> fail:
> {code}java.lang.NoClassDefFoundError: org/mortbay/util/ajax/JSON
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.jsonParse(WebHdfsFileSystem.java:277)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.getResponse(WebHdfsFileSystem.java:561)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.run(WebHdfsFileSystem.java:480)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:413)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHdfsFileStatus(WebHdfsFileSystem.java:580)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getFileStatus(WebHdfsFileSystem.java:591)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1332)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9471) hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
[
https://issues.apache.org/jira/browse/HADOOP-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated HADOOP-9471:
---
Target Version/s: 2.0.4-alpha
Fix Version/s: (was: 2.0.4-alpha)
> hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
> --
>
> Key: HADOOP-9471
> URL: https://issues.apache.org/jira/browse/HADOOP-9471
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.3-alpha
>Reporter: Alejandro Abdelnur
>Assignee: Alejandro Abdelnur
> Attachments: HADOOP-9471.patch
>
>
> WebHdfsFileSystem uses jetty-util's JSON class.
> hadoop-client excludes that JAR, applications built using hadoop-client POM
> fail:
> {code}java.lang.NoClassDefFoundError: org/mortbay/util/ajax/JSON
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.jsonParse(WebHdfsFileSystem.java:277)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.getResponse(WebHdfsFileSystem.java:561)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.run(WebHdfsFileSystem.java:480)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:413)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHdfsFileStatus(WebHdfsFileSystem.java:580)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getFileStatus(WebHdfsFileSystem.java:591)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1332)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9471) hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
[
https://issues.apache.org/jira/browse/HADOOP-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated HADOOP-9471:
---
Resolution: Fixed
Fix Version/s: 2.0.5-beta
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Committed to trunk and branch-2, CHANGES.txt under 2.0.5. If it makes it to
2.0.4-alpha, CHANGES.txt in trunk and branch-2 should be updated.
> hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
> --
>
> Key: HADOOP-9471
> URL: https://issues.apache.org/jira/browse/HADOOP-9471
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.3-alpha
>Reporter: Alejandro Abdelnur
>Assignee: Alejandro Abdelnur
> Fix For: 2.0.5-beta
>
> Attachments: HADOOP-9471.patch
>
>
> WebHdfsFileSystem uses jetty-util's JSON class.
> hadoop-client excludes that JAR, applications built using hadoop-client POM
> fail:
> {code}java.lang.NoClassDefFoundError: org/mortbay/util/ajax/JSON
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.jsonParse(WebHdfsFileSystem.java:277)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.getResponse(WebHdfsFileSystem.java:561)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.run(WebHdfsFileSystem.java:480)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:413)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHdfsFileStatus(WebHdfsFileSystem.java:580)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getFileStatus(WebHdfsFileSystem.java:591)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1332)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HADOOP-9471) hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
[
https://issues.apache.org/jira/browse/HADOOP-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628686#comment-13628686
]
Hudson commented on HADOOP-9471:
Integrated in Hadoop-trunk-Commit #3592 (See
[https://builds.apache.org/job/Hadoop-trunk-Commit/3592/])
HADOOP-9471. hadoop-client wrongfully excludes jetty-util JAR, breaking
webhdfs. (tucu) (Revision 1466763)
Result = SUCCESS
tucu : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1466763
Files :
* /hadoop/common/trunk/hadoop-client/pom.xml
* /hadoop/common/trunk/hadoop-common-project/hadoop-common/CHANGES.txt
> hadoop-client wrongfully excludes jetty-util JAR, breaking webhdfs
> --
>
> Key: HADOOP-9471
> URL: https://issues.apache.org/jira/browse/HADOOP-9471
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.3-alpha
>Reporter: Alejandro Abdelnur
>Assignee: Alejandro Abdelnur
> Fix For: 2.0.5-beta
>
> Attachments: HADOOP-9471.patch
>
>
> WebHdfsFileSystem uses jetty-util's JSON class.
> hadoop-client excludes that JAR, applications built using hadoop-client POM
> fail:
> {code}java.lang.NoClassDefFoundError: org/mortbay/util/ajax/JSON
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.jsonParse(WebHdfsFileSystem.java:277)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.getResponse(WebHdfsFileSystem.java:561)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem$Runner.run(WebHdfsFileSystem.java:480)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:413)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHdfsFileStatus(WebHdfsFileSystem.java:580)
> at
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getFileStatus(WebHdfsFileSystem.java:591)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1332)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9452) Windows install scripts bugfixes
[ https://issues.apache.org/jira/browse/HADOOP-9452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Mitic updated HADOOP-9452: --- Attachment: HADOOP-9452.branch-1-win.installerfixes.2.patch Attaching the new patch. Newly added properties will now be nicely formatted in the conf xml. Kanna, Suresh, this patch is ready for the final review. > Windows install scripts bugfixes > > > Key: HADOOP-9452 > URL: https://issues.apache.org/jira/browse/HADOOP-9452 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 1-win >Reporter: Ivan Mitic >Assignee: Ivan Mitic > Attachments: HADOOP-9452.branch-1-win.installerfixes.2.patch, > HADOOP-9452.branch-1-win.installerfixes.patch > > > A few bugfixes we've done to install scripts on Windows. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9472) Cleanup hadoop-config.cmd
Ivan Mitic created HADOOP-9472: -- Summary: Cleanup hadoop-config.cmd Key: HADOOP-9472 URL: https://issues.apache.org/jira/browse/HADOOP-9472 Project: Hadoop Common Issue Type: Bug Affects Versions: 1-win Reporter: Ivan Mitic Assignee: Ivan Mitic Priority: Minor Some portions of hadoop-config.cmd script are unused and should be cleaned up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HADOOP-9472) Cleanup hadoop-config.cmd
[ https://issues.apache.org/jira/browse/HADOOP-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Mitic updated HADOOP-9472: --- Attachment: HADOOP-9472.branch-1-win.cleanup.patch Attaching the patch. > Cleanup hadoop-config.cmd > - > > Key: HADOOP-9472 > URL: https://issues.apache.org/jira/browse/HADOOP-9472 > Project: Hadoop Common > Issue Type: Bug >Affects Versions: 1-win >Reporter: Ivan Mitic >Assignee: Ivan Mitic >Priority: Minor > Attachments: HADOOP-9472.branch-1-win.cleanup.patch > > > Some portions of hadoop-config.cmd script are unused and should be cleaned up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
