accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3952) bin/accumulo should verify log4j.jar was found
Date Mon, 03 Aug 2015 22:47:05 GMT

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

Christopher Tubbs commented on ACCUMULO-3952:
---------------------------------------------

bq. If that does work, it's news to me and I would call it an undocumented/subject-to-change
feature.

I fixed that with ACCUMULO-3685, because it was a long-standing issue, and I was correcting
the bootstrap classpath issues. So, it has worked that way since at least 1.7.0 (but probably
not before). I suppose it is an undocumented feature, but it's one I'd expect for a Java app.
After all, I wouldn't exactly consider it normal behavior for a launch script to clobber-and-ignore
standard user preferences/environment variables that affect the behavior of the thing it is
launching, especially a "PATH" environment variable, where it is typical to append/prepend
vs. clobber.

bq. Very much of a problem? It's a fail very poorly situation if the log4j jar can't be found.
I had to try very had to get a stacktrace.

I agree it's definitely a problem. I suppose I was trying to ask how much of a problem that
the script doesn't do the check vs. Java doing the check. Either way, the error needs to be
more prominent. I'm just not sure to what extent we can preemptively check for required classes
in the scripts, when the classes could be in different jars.

I guess I was trying to ask whether we should consider these "required" locations, or "expected"
locations, which would determine slightly different behavior and messages.

bq. I think it's very trivial to check the "start" classpath (slf4j and log4j) which is all
I intended to check.

It's trivial to check for files with particular names, but it's less trivial to check for
required classes being contained in those jars. So, this goes back to my question about "required"
vs. "expected". Do we require that those specific classes be loaded from jars in those specific
locations by those specific names? How much checking are you thinking is needed? At a certain
point, Java's going to do a much more thorough checking than we could, for the requisite classes.

Maybe it's just better to ensure that the CNFE is propagated better from Java, rather than
implement our own checking? Or maybe we still want to do a minimal "sanity check" to see if
the file with the expected name exists?

> bin/accumulo should verify log4j.jar was found
> ----------------------------------------------
>
>                 Key: ACCUMULO-3952
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3952
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: scripts
>    Affects Versions: 1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.7.0
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: 1.6.4, 1.7.1, 1.8.0
>
>
> Just spent a few hours trying to wrangle this one down. Ambari was failing to start all
Accumulo components. After digging in, I realized that when Ambari was invoking {{accumulo}},
it was failing to find the log4j jar.
> It turns out this was a deployment issue where the home directory for the {{accumulo}}
user was never created and the find command failed:
> {noformat}
> find: cannot stat current directory: Permission denied
> {noformat}
> Sadly, I couldn't find this error until I manually edited the accumulo script to remove
the {{2>/dev/null}} redirect. We should have been able to realize that we never found the
log4j jar and then clearly printed an error and exited instead of leading me on a goosechase
by silently proceeding.
> Same goes for the slf4j jars.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message