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 generally should be verbose, and tuning it down when needed is just part of tuning the system imho. Once an event has passed un-logged, it's gone and the clue to what happened is missing and the developer has to spend time to even know what log to turn on, if it's even reproducible. If we do anything, it ought to be some sort of logging profiles (beyond -q and -v I suppose), but it seems to me we have lots of configurability there already https://lucene.apache.org/solr/guide/7_5/configuring-logging.html.
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. This would also be nice for cases where you want the logging config to live outside of the install where someone can easily play with it. -Gus On Wed, Nov 21, 2018 at 5:50 PM Uwe Schindler <u...@thetaphi.de> wrote: > 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 does the same. Every compiled Lucene expression has the same class > name, just in a different classloader. > > So every core has its own copy of all classes. That's a common problem for > users with many cores each of those having Tika configured per core only... > > Uwe > > Am November 21, 2018 10:23:29 PM UTC schrieb Shawn Heisey < > apa...@elyograg.org>: >> >> 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 by spewing out that for first-time users of Solr who really >>> just care for whether >>> the server started OK or not. >>> >> >> If somebody's got a config that loads 150 jars, I really do think that >> having that info in the log would be useful information. That's a LOT >> of jars, and it could be vital for troubleshooting a classloader problem >> with one jar -- need to be able to tell whether it has been loaded or not. >> >> It definitely shouldn't be default to have Jetty log its jar loading. I >> just want to know how to make it do so, for situations that require very >> in-depth study. >> >> A user who's got 20 cores and each of them is loading the same 10 jars >> with <lib> config ... IMHO that would ALSO be useful information to be >> able to see in the default log. Without it, the user will probably have >> absolutely no idea that they have 200 jar loads. (when that happens, >> does Java realize that the classloader is loading the same jars and >> eliminate duplicates in memory?) >> >> Thanks, >> Shawn >> ------------------------------ >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > -- > Uwe Schindler > Achterdiek 19, 28357 Bremen > https://www.thetaphi.de > -- http://www.the111shift.com
