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 there's a way to shut them off. The only logging config files you should have to worry about are in ./solr/server/resources..... But yeah, there are several Solr JIRAs lying around that I'll break some time loose _sometime_ to work on to try to make logging more rational. Unfortunately as Shawn says, there's always tension. When running "normally", I pretty much only want to see WARN messages. Then every time I want to diagnose something, I want to see _everything_. And telling the user to change their logging and call me again next time the problem happens is not very satisfying for anyone. Best, Erick On Tue, Nov 20, 2018 at 6:40 PM Shawn Heisey <[email protected]> wrote: > > 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 would be very nice. > > A quick check of the SolrResourceLoader code suggests that if the > logging level for that class were changed to DEBUG, it would nicely > provide the info that I'm after, wouldn't log a huge amount of useless > cruft, and wouldn't even require a code change. Maybe we could put this > config in log4j2.xml, commented out, as an option that the end user > could enable if they wish. > > Another solution would be to create a special logger, along the lines of > the ones in SolrCore that log requests and slow requests, and have log4j > config for that special logger. And that's not necessarily a bad idea, > but I think the idea mentioned above is good enough, and a lot easier. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
