How much of this controlled by log4j property file and we can include
usecases as commented out things to let people choose?
Because we can set the logging very precisely without recompiling.
Regards,
Alex
On Tue, Nov 20, 2018, 7:21 PM Shawn Heisey <[email protected] wrote:
> On 11/20/2018 4:09 PM, Jan Høydahl wrote:
> > In Solr 6.3 (SOLR-6677) we reduced a lot of noisy logging in the default
> start/stop scenario. We ended up with a very compact set of log lines. I
> just realized that this is getting fatter for every release, and now a solr
> start -f looks like this on my laptop:
>
> <snip>
>
> > Am I alone valuing a much more minimalistic output and hiding stuff that
> won't add value? After pruning away what I see no value in, here's what I
> end up with:
>
> <snip>
>
> > That's from 31 to 12 lines. I don't want to see file limit warnings on a
> dev laptop, and Jetty's lack of JSP support is totally irrelevant :)
>
> I wonder what we need to do with Jetty to make that log line go away.
> It's thankfully only one line! I worry about changing the log level for
> o.e.j.w.StandardDescriptorProcessor to WARN or ERROR ... I wonder if
> that might get rid of messages that we would actually want to see. Have
> to ask the jetty mailing list. I can do that, unless you'd really like
> to do it.
>
> > The line "SSLCredentialProviderFactory Processing SSL Credential
> Provider chain: env;sysprop" is also popping up even in non-SSL and for
> things like bin/solr status. Why?
>
> That does look like a good candidate for changing to DEBUG.
>
> > If you all agree I'll open a JIRA and solve some of this with
> INFO->DEBUG changes, and others in log4j2.xml (e.g. o.e.j.s.session -> WARN)
>
> I agree with the general direction of making the logs leaner. But, if I
> may drag out the soapbox for a moment, there are some things that have
> been removed from default logs that I would like to be restored. The
> one on my mind right now: A list of every file (usually jars) loaded by
> <lib> config elements or a file's presence in ${solr.solr.home}/lib or
> ${instanceDir}/lib. I think that information adds a LOT of value to the
> logs. I know that it can be a lot of lines, though.
>
> If consensus is to not log that by default, which I completely
> understand, then can we put a config element in solrconfig.xml that
> would instruct Solr to log files loaded after startup, at the INFO level
> instead of DEBUG? I do not like the option of starting Solr with the -v
> flag -- this does get the info I'm after, but the logfile has way too
> much OTHER cruft that is not helpful. Some of the tougher problems to
> diagnose on the user list include ClassNotFoundException, and that would
> be a lot easier if the logfile included a list of every jar loaded after
> the moment that Jetty starts Solr. Having Jetty log every jar loaded
> *before* it starts Solr might also be useful, but I'll need to ask about
> that on the Jetty list.
>
> Having Solr log Java's classpath would be a welcome addition for the
> same reason, and that would only be one long line.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
