[
https://issues.apache.org/jira/browse/CASSANDRA-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069676#comment-13069676
]
Jackson Chung commented on CASSANDRA-2895:
------------------------------------------
sure. First off, I will start by saying it is absolutely possible to still
obtain the classpath from other techniques, such as jconsole, jinfo, ps,
/proc/<pid>/cmdline, etc. All these are doable providing using it properly.
Some common typical challenges on these "other techniques": PATH is difference
for the user who starts cassandra vs user who ssh into the machine and check,
resulting in cannot attach the jvm due to jvm mismatched. Cannot attach
remotely due to permission. ps result truncated. /proc/<pid>cmdline result is
ugly (no separator).
We need to know the classpath info to identify which jars contains the classes.
Granted knowing "just" the classpath is not enough as one would still need to
verify that actual path/jar exists (and with proper permission). Down the road
when hotfixes accumulated (and for the sake of arguments in a scenario where
the hotfix only contains fixed classes, but not the whole build), we would need
to identify if a hotfix (jar) is properly set in the classpath to validate the
java process is running with the hotfix.
a real (small) example:
INFO [main] 2011-07-22 11:34:10,113 CLibrary.java (line 61) JNA not found.
Native methods will be disabled.
well from a end-user perspective, not found "where"? Of course a
java-experienced user would most likely intuitively think of class path. But
for others it may not be obvious. Further support analysts will need to do
his/her own analysis to determine if the jna.jar is on the classpath and in the
said-location. (ie jna.jar is in /path/to/ but classpath said
/path/to/others/). This could be further challenged if it needs to be done
remotely or the analyst has no direct access to the machine.
Hence the classpath info is one of the more important info for someone who
understand not just Cassandra, but java in general of what it is doing.
As to oppose using DEBUG: currently the logging does not have a "header" sets.
Ie the log is logged once and wouldn't appear again. Logging at DEBUG for some
that only logged once at startup means one would have to restart the jvm to see
the log. That seems overkill for just simply get a log. One may as well
learn/try to use jinfo/jconsole/ps/cmdline to get that info.
I agree we wouldn't want every bit of details (that say available via jinfo) to
be logged, that would noise the log quite a bit. On the other hand, the
classpath itselfs provides a quick and strong validation to properly identify
any misconfiguration on classpath settings.
> add java classpath to cassandra startup logging
> -----------------------------------------------
>
> Key: CASSANDRA-2895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2895
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jackson Chung
> Priority: Minor
> Attachments: 2895.diff
>
>
> this is helpful to determine/verify if the Cassandra is started with the
> expected classpath
> it's a simple 1-liner addon that are useful... will submit a patch later.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
