hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-6605) Add JAVA_HOME detection to hadoop-config
Date Fri, 20 May 2011 14:32:47 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-6605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036849#comment-13036849

Daryn Sharp commented on HADOOP-6605:

(btw, I previously attempted to imply my neg was withdrawn, but I just want to make it unambiguously
clear.  I really like the idea as evidenced by my jira dupped to this one)

bq. From googling it looked like "jdk1.6.0" was a stable path on Solaris, ie no glob necessary.
Maybe someone who uses Solaris can verify, I'm fine punting Solaris to a future change as

My only point/concern is that if a jdk1.6.1. or jdk1.6.2 is installed that this implementation
would still default to 1.6.0.  What if a 1.6.1, but not 1.6.0, is installed?  Or if only jdk1.7.*
is installed and perhaps hadoop works fine with either java 6 or 7?  The detection is of little
use to the user, however I don't know the Solaris conventions.  Maybe they have a way to set
a "default" java?  Perhaps a symlink somewhere?  I have no strong feelings, and punting would
be fine, or maybe a Solaris user could chime in.

bq. These globs should not result in a lot more paths being added. Eg how many paths would
you expect "/usr/java/jdk1.6*" to match on most systems? Probably none, a couple would be
a lot right? Even if these globs matched 20 paths per above it shouldn't impact performance.

Don't worry, I have no performance concerns.  I fully agree a few stat calls is minuscule
in the overall execution.  My mild concern is the maintainability introduced by having to
update paths for newer versions of java. However, being a stickler for consistency, I have
a little more concern about how updating the paths introduces inconsistent behavior in how
the jdk is selected.  Then again, perhaps Linux folks are accustomed to inconsistency? :)

bq. bq. Linux - Same as SunOS. Also, why aren't /usr/java/default and /usr/lib/jvm/default-java
checked first?

bq. The code looks for Sun Java 6 first because Hadoop depends on Sun Java 6, ie we don't
necessarily want the system default Java.

Only for the sake of discussion: If the goal is be a "good citizen" of the host os, then picking
the system default is sufficient.  This approach should eliminate the need to periodically
update the script to pick the newer "preferred" java versions, and remove the inconsistency
in how the java version is selected between hadoop releases.  It would parallel the Mac/Darwin
detection, ie. use the system's default method (if there is one), and if the user wants a
different version then they must either change the system default or explicitly set JAVA_HOME.

> Add JAVA_HOME detection to hadoop-config
> ----------------------------------------
>                 Key: HADOOP-6605
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6605
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Chad Metcalf
>            Assignee: Eli Collins
>            Priority: Minor
>             Fix For: 0.22.0
>         Attachments: HADOOP-6605.patch, hadoop-6605-1.patch, hadoop-6605-2.patch
> The commands that source hadoop-config.sh currently bail with an error if JAVA_HOME is
not set. Let's detect JAVA_HOME (from a list of locations on various OS types) if JAVA_HOME
is not already set by hadoop-env.sh or the environment. This way users don't have to manually
configure it.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message