lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera" <ser...@gmail.com>
Subject Re: Java logging in Lucene
Date Mon, 08 Dec 2008 14:02:11 GMT
{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 <earwin@gmail.com> 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 <serera@gmail.com> 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 <gsingers@apache.org>
> 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: java-dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: java-dev-help@lucene.apache.org
> >>
> >
> >
>
>
>
> --
> Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
> ICQ: 104465785
>
Mime
View raw message