You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2018/03/15 17:02:00 UTC

[jira] [Comment Edited] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3

    [ https://issues.apache.org/jira/browse/HBASE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16400737#comment-16400737 ] 

Josh Elser edited comment on HBASE-20201 at 3/15/18 5:01 PM:
-------------------------------------------------------------

{quote}So, roll back our commons-cli? If we remove it, what breaks? We need it?
{quote}
That is a #3 option, but I think a bad one. Appy brought it in for some good reasons (see the RN on HBASE-17050).
{quote}Best as I can tell for H2, we'd be broken in the same manner as we are for H3. I can only guess that the reason we haven't seen this previously is due to jobs that don't use the AbstractHBaseTool
{quote}
I did poke at this some more last night: we've missed it in our testing because we don't use {{hadoop jar}} to run our {{Tool}}'s. Hadoop has been on commons-cli 1.2 for a while now, and we haven't gotten hbase2 in the hands of folks who have {{hadoop jar}} in their workflow. I think third-party inclusion is the "right" solution (just "sighing" because it's the most work). Would you be OK with me trying my hand at that, [~stack]?


was (Author: elserj):
{quote}So, roll back our commons-cli? If we remove it, what breaks? We need it?
{quote}
That is a #3 option, but I think a bad one. Appy brought it in for some good reasons (see the RN on HBASE-17050).
{quote}Best as I can tell for H2, we'd be broken in the same manner as we are for H3. I can only guess that the reason we haven't seen this previously is due to jobs that don't use the AbstractHBaseTool
{quote}
I did poke at this some more last night: we've missed it in our testing because we don't use {{hadoop jar}} to run our {{Tool}}s. Hadoop has been on commons-cli 1.2 for a while now, and we haven't gotten hbase2 in the hands of folks who have {{hadoop jar}} in their workflow. I think third-party inclusion is the "right" solution (just "sighing" because it's the most work). Would you be OK with me trying my hand at that, [~stack]?

> HBase must provide commons-cli-1.4 for mapreduce jobs with H3
> -------------------------------------------------------------
>
>                 Key: HBASE-20201
>                 URL: https://issues.apache.org/jira/browse/HBASE-20201
>             Project: HBase
>          Issue Type: Bug
>          Components: mapreduce
>            Reporter: Romil Choksi
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 2.0.0
>
>
> Been trying to get some pre-existing mapreduce tests working against HBase2.
> There's an inherent problem right now that hadoop-common depends on commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, you'll get an error like:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/cli/DefaultParser
>     at org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165)
>     at org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133)
>     at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
>     at org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270)
>     at hbase_it.App.main(App.java:85)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at org.apache.hadoop.util.RunJar.run(RunJar.java:239)
>     at org.apache.hadoop.util.RunJar.main(RunJar.java:153)
> Caused by: java.lang.ClassNotFoundException: org.apache.commons.cli.DefaultParser
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>     ... 11 more{noformat}
> My guess is that in previous versions, we didn't have this conflict with Hadoop (we were on the same version). Now, we're not.
> I see two routes:
>  # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} environment variable
>  # We put commons-cli into our hbase-thirdparty and stop using it directly.
> The former is definitely quicker, but I'm guessing the latter would insulate us more nicely.
> Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)