[
https://issues.apache.org/jira/browse/SOLR-12005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16370497#comment-16370497
]
Shawn Heisey commented on SOLR-12005:
-------------------------------------
{quote}
Dunno, If you specify the -v option when starting Solr, does that provide the
information you want?
{quote}
Yes ... but it also logs thousands of lines of cruft that is simply not useful
for basic troubleshooting when the issue is *probably* user error. DEBUG logs
are useful for problems where we suspect that Solr has a bug, to verify whether
or not it's working by seeing internal state as the code runs. But even then,
it's more useful to turn on DEBUG logging for individual classes (either in
log4j.properties or in the admin UI), not the entire logging config.
We could figure out how to modify log4j.properties so that SolrResourceLoader
is increased to DEBUG, and have users turn that on when troubleshooting these
issues. If that's really what everyone thinks we should do, it can even go in
the reference guide, and it could be in log4j.properties already, but
commented. I am not opposed to this idea, it just wasn't the first thing I
thought of.
For my servers, the change would result in eight additional lines being logged
by default – the eight jars that I have in ${solr.solr.home}/lib. Or perhaps
nine lines, as there might be a line indicating which directory is being
examined. I do not have <lib> elements in any solrconfig.xml file. This isn't
eight lines for every core (of which I have a couple dozen per server) ... but
eight lines total. For out of the box users, there would be no increase in
logging.
{noformat}
2018-02-20 18:38:18.768 DEBUG (main) [ ] o.a.s.c.SolrResourceLoader Adding
'file:/index/solr6/data/lib/solr-dataimporthandler-6.6.2-SNAPSHOT.jar' to
classloader
2018-02-20 18:38:18.768 DEBUG (main) [ ] o.a.s.c.SolrResourceLoader Adding
'file:/index/solr6/data/lib/ncSolrUpdateProcessors.jar' to classloader
2018-02-20 18:38:18.768 DEBUG (main) [ ] o.a.s.c.SolrResourceLoader Adding
'file:/index/solr6/data/lib/jblas-1.2.4.jar' to classloader
2018-02-20 18:38:18.768 DEBUG (main) [ ] o.a.s.c.SolrResourceLoader Adding
'file:/index/solr6/data/lib/icu4j-56.1.jar' to classloader
2018-02-20 18:38:18.768 DEBUG (main) [ ] o.a.s.c.SolrResourceLoader Adding
'file:/index/solr6/data/lib/mysql-connector-java-5.1.40-bin.jar' to classloader
2018-02-20 18:38:18.768 DEBUG (main) [ ] o.a.s.c.SolrResourceLoader Adding
'file:/index/solr6/data/lib/CJKFoldingFilter.jar' to classloader
2018-02-20 18:38:18.768 DEBUG (main) [ ] o.a.s.c.SolrResourceLoader Adding
'file:/index/solr6/data/lib/lucene-analyzers-icu-6.6.2-SNAPSHOT.jar' to
classloader
2018-02-20 18:38:18.768 DEBUG (main) [ ] o.a.s.c.SolrResourceLoader Adding
'file:/index/solr6/data/lib/pixolution_flow3.2.0_solr6.6.0.jar' to classloader
{noformat}
If the user enables a config option to turn on additional jar logging, there
may be a lot more lines logged. This is what Solr 7.2.1 logs out of the box for
a core startup of a core using the _default configset:
{code:java}
2018-02-20 18:59:22.041 INFO (coreLoadExecutor-6-thread-1) [ x:foo]
o.a.s.c.SolrResourceLoader [foo] Added 53 libs to classloader, from paths:
[/C:/Users/sheisey/Downloads/solr-7.2.1/contrib/clustering/lib,
/C:/Users/sheisey/Downloads/solr-7.2.1/contrib/extraction/lib,
/C:/Users/sheisey/Downloads/solr-7.2.1/contrib/langid/lib,
/C:/Users/sheisey/Downloads/solr-7.2.1/contrib/velocity/lib,
/C:/Users/sheisey/Downloads/solr-7.2.1/dist]
{code}
That's 53 files loaded for one core, and the <lib> config in solrconfig.xml
ensures they're all jar files. I totally understand the desire to eliminate
those lines from the default logging. For the average user that never uses any
custom plugins or anything from contrib (like analysis-extras) that is not in
the default example, that information doesn't help them, and may actually
confuse them.
If the solr.xml option I've mentioned were enabled and the user's server had a
handful of cores with solrconfig.xml files mostly unchanged from the default
example, they would have a few hundred extra lines in their log. Each extra
line would not be horrendously verbose, and the information is usually relevant
to somebody trying to figure out a problem that involves that config option.
And also remember that these lines would NOT be logged without enabling the
config.
> Solr should have the option of logging all jars loaded
> ------------------------------------------------------
>
> Key: SOLR-12005
> URL: https://issues.apache.org/jira/browse/SOLR-12005
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Shawn Heisey
> Priority: Major
>
> Solr used to explicitly log the filename of every jar it loaded. It seems
> that the effort to reduce the verbosity of the logs has changed this, now it
> just logs the *count* of jars loaded and the paths where they were loaded
> from. Here's a log line where Solr is reading from ${solr.solr.home}/lib:
> {code}
> 2018-02-01 17:43:20.043 INFO (main) [ ] o.a.s.c.SolrResourceLoader [null]
> Added 8 libs to classloader, from paths: [/index/solr6/data/lib]
> {code}
> When trying to help somebody with classloader issues, it's more difficult to
> help when the list of jars loaded isn't in the log.
> I would like the more verbose logging to be enabled by default, but I
> understand that many people would not want that, so I propose this:
> * Enable verbose logging for ${solr.solr.home}/lib by default.
> * Disable verbose logging for each core by default. Allow solrconfig.xml to
> enable it.
> * Optionally allow solr.xml to configure verbose logging at the global level.
> ** This setting would affect both global and per-core jar loading. Each
> solrconfig.xml could override.
> Rationale: The contents of ${solr.solr.home}/lib are loaded precisely once,
> and this location doesn't even exist unless a user creates it. An
> out-of-the-box config would not have verbose logs from jar loading.
> The solr home lib location is my preferred way of loading custom jars,
> because they get loaded only once, no matter how many cores you have. Jars
> added to this location would add lines to the log, but it would not be logged
> for every core.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
