I referred to the case when you want normal production logs, like
access logs, or whatever.
Debugging with all common logging implementations is also broken,
because switching logging on/off dramatically changes multithreading
picture.
On Mon, Dec 8, 2008 at 17:02, Shai Erera <[EMAIL PROTECTED]> wrote:
> {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
>
>
--
Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED])
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
