> There's already LOG4J_PROPS so if you have a favorite log4j config you
> want to use, just set that env variable and forget about it, does that
> work?
>
>
That sounds great, now if only it were in the docs :)
https://lucene.apache.org/solr/guide/7_5/configuring-logging.html
I'll add it later
On 11/27/2018 7:29 AM, Gus Heck wrote:
Startup logging that happens just on startup should err on the side of
verbosity.
I think this is a good policy.
As I said before, I really do applaud the efforts to shrink the logs and
eliminate cruft. But I don't think that the motivation and goal
I’m not a big fan of console/file magic. If that is done, there needs to be a
big WARN at the beginning that says some log messages are suppressed because a
console has been detected.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Nov 27, 2018, at
Maybe we can have it both ways: might the distinction be done between
console & files? So for example keep the console more brief, but have the
log files contain more logs? Just an idea.
On Tue, Nov 27, 2018 at 8:07 AM Erick Erickson
wrote:
> bq: Maybe the real thing to do since everyone's
bq: Maybe the real thing to do since everyone's preferences vary is to
have a --log-config start script option that points solr at one's
favorite dev/testing/demo oriented logging config
There's already LOG4J_PROPS so if you have a favorite log4j config you
want to use, just set that env variable
Startup logging that happens just on startup should err on the side of
verbosity. I like the ulimit checks even if they are sometimes irrelevant
on my dev systems, the lib listing also sounds useful. Of course truly
useful things like the jetty jsp message should be eliminated. Default
logging
No it won't deduplicate. It is actually worse: Every class would be a different
class instance per core, just with same name (they won't even compare equals to
each other). This why you have classloader, so you can have same class name in
different parts of app. OSGI... The expressions module
On 11/21/2018 1:40 AM, Jan Høydahl wrote:
It is super easy to change the log level of one particular class or
package
selectively, that's why we have log4j2.xml and also the Admin's
Logging levels menu.
The occational need to see all of the 150 jar files loaded on startup
should not be
solved
bq. t is super easy to change the log level of one particular class or package
If anyone has prod logs laying around collected at INFO level and could
provide any counts of what packages the most frequent log messages come
from, please attach the data to SOLR-11934. I've seen some cases where
> bq. I don't want to see file limit warnings on a dev laptop
>
> "If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to
> false in your profile or solr.in.sh"
>
> Not having these limits set properly has caused weird errors for a lot
> of people, but I agree they are annoying at
bq. I don't want to see file limit warnings on a dev laptop
"If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to
false in your profile or solr.in.sh"
Not having these limits set properly has caused weird errors for a lot
of people, but I agree they are annoying at times so
On 11/20/2018 5:34 PM, Alexandre Rafalovitch wrote:
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.
If we can control it with log4j config, that
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 On 11/20/2018 4:09 PM, Jan Høydahl 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
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:
$ solr start -f
*** [WARN] ***
15 matches
Mail list logo
