{quote}
My research shows there are no ready-made java logging frameworks that can
be used in high-load production environment.
{quote}I'm not sure I understand what you mean by that. We use Java logging in our high-profiled products, which support 100s of tps. Logging is usually turned off, and is being turned on only for debugging. We have not seen any problems with Java logging at runtime (i.e., w/o logging, when only logger.isLoggable calls are made) or at debug-time (when actual logging happens). Of course, at debug-time performance is slower, but that's debug time - you're not into performance, but for debugging. Anyway, as far as SLF4J goes, I've written a patch using it, and replacing infoStream. I'm about to open an issue and submit the patch, for everyone to review. We can continue the discussion there. Shai On Mon, Dec 8, 2008 at 10:13 AM, Earwin Burrfoot <[EMAIL PROTECTED]> wrote: > The common problem with native logging, log4j and slf4j (logback impl) > is that they are totally unsuitable for actually logging something. > They do good work checking if the logging can be avoided, but use > almost-global locking if you really try to write this line to a file. > My research shows there are no ready-made java logging frameworks that > can be used in high-load production environment. > > On Sat, Dec 6, 2008 at 19:52, Shai Erera <[EMAIL PROTECTED]> wrote: > > On the performance side, I don't expect to see any different performance > > than what we have today, since checking if infoStream != null should be > > similar to logger.isLoggable (or the equivalent methods from SLF4J). > > > > I'll look at SLF4J, open an issue and work out a patch. > > > > On Sat, Dec 6, 2008 at 1:22 PM, Grant Ingersoll <[EMAIL PROTECTED]> > wrote: > >> > >> On Dec 5, 2008, at 11:36 PM, Shai Erera wrote: > >> > >>> > >>> What do you have against JUL? I've used it and in my company (which is > >>> quite a large one btw) we've moved to JUL just because it's so easy to > >>> configure, comes already with the JDK and very intuitive. Perhaps it > has > >>> some shortcomings which I'm not aware of, and I hope you can point me > at > >>> them. > >> > >> See http://lucene.markmail.org/message/3t2qwbf7cc7wtx6h?q=Solr+logging(or > >> > http://grantingersoll.com/2008/04/25/logging-frameworks-considered-harmful/for > >> my rant on it!) Frankly, I could live a quite happy life if I never had > to > >> think about logging frameworks again! > >> > >> As for JUL, the bottom line for me is (and perhaps I'm wrong): It > doesn't > >> play nice with others (show me a system today that uses open source > projects > >> which doesn't have at least 2 diff. logging frameworks) and it usually > >> requires coding where other implementations don't. My impression of JUL > is > >> that the designers wanted Log4j, but somehow they felt they had to come > up > >> with something "original", and in turn arrived at this thing that is the > >> lowest common denominator. But, like I said, it's a religious debate, > eh? > >> ;-) > >> > >> As for logging, you and Jason make good points. I guess the first thing > >> to do would be to submit a patch that adds SLF4J instead of infoStream > and > >> then we can test performance. It still amazing, to me, however, that > Lucene > >> has made it this long with all but rudimentary logging and only during > >> indexing. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > > > -- > Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED]) > Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 > ICQ: 104465785 >
