Howdy,

>I don't see your point. If you put the logged messages to a circular buffer
>that holds say 16k messages at a time, then you won't have high memory
>usage just 16k*size of a logged message. Of course if your code if full of
>debug logging, then the program will be slow, but on the other hand will
>give you very valuable feedback in case of an exception/error.

16k times the size of a logged message can be large, first of all.  Secondly, that 
amount might be multiplied many times by having a separate buffer for each logger.

Secondly, I like to be able to make the tradeoff of performance versus information 
myself, i.e. via configuration and reconfiguration at runtime.  I will not accept a 
system that always keeps an extra 16k messages in case there's an error.

I'm not saying this feature is a completely bad idea.  It can be useful in certain 
cases.  However:
- log4j is in a sweet spot performance-wise, and care should be taken to maintain that.
- When someone is considering moving to log4j from another package, complaining of the 
other package's performance, and then asks to add a feature that seems like a 
performance hog to log4j, that's a red flag for me.

I will be glad to be convinced otherwise by a benchmark, however...

Yoav Shapira


>
>> -----Original Message-----
>> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
>> Sent: Monday, August 11, 2003 3:29 PM
>> To: Log4J Users List
>> Subject: RE: log4j: dump wrap-around buffer of all log messages
>>
>>
>>
>> Howdy,
>> I would really want this sort of feature benchmarked for
>> memory use ;)  Perhaps this is one of the reasons log4j has
>> better performance than your current java trace kit ;)
>>
>> Yoav Shapira
>> Millennium ChemInformatics
>>
>>
>> >-----Original Message-----
>> >From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
>> >Sent: Monday, August 11, 2003 9:24 AM
>> >To: Log4J Users List
>> >Subject: Re: log4j: dump wrap-around buffer of all log messages
>> >
>> >
>> >Yes, this is certainly possible. The SMTPAppender works in a similar
>> >fashion.
>> >
>> >At 03:09 PM 8/11/2003 +0200, you wrote:
>> >>Dear log4j users,
>> >>
>> >>
>> >>Currently I'm evaluating log4j 1.2.8 to replace an other Java Trace
>> >package
>> >>(see http://visibleworkings.com/trace/) in our
>> applications. Log4j's big
>> >>advantage is its performance, but still I'm missing a
>> feature that is
>> >>present in the Java Trace package: the ability to dump a wrap-around
>> >buffer
>> >>of, let's say, the last 500 log messages in the log file.
>> >>
>> >>The wrap-around buffer (think of it as an array of let's say 500 log
>> >>messages) contains at any moment, the last 500 log
>> messages. The idea is
>> >>that the logger has 2 log levels: one which determines what level is
>> >present
>> >>in the log file (or std out or whatever), another which
>> determines at what
>> >>level the internal wrap-around buffer is filled with
>> messages. This way,
>> >it
>> >>is possible to let your application log at level INFO,
>> while the internal
>> >>buffer keeps all messages of level DEBUG or higher. When an
>> exception is
>> >>thrown, the user should have the ability to request a dump
>> of the buffer,
>> >>such that the more detailed DEBUG messages are also present
>> in the log
>> >file
>> >>to make debugging more easy.
>> >>
>> >>Is this possible in log4j? If not, has anyone a workaround
>> for this or
>> >>should I ask for a feature request?
>> >>
>> >>
>> >>Kind regards,
>> >>Patrick Hancke
>> >>Siemens Atea IC D BS PD2
>> >>tel ++32(0)14 - 25 24 27
>> >>fax ++32(0)14 - 25 30 25
>> >>
>> >>------------------------------------------------------------
>> ---------
>> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >--
>> >Ceki For log4j documentation consider "The complete log4j manual"
>> >      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>> >
>> >
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>> This e-mail, including any attachments, is a confidential
>> business communication, and may contain information that is
>> confidential, proprietary and/or privileged.  This e-mail is
>> intended only for the individual(s) to whom it is addressed,
>> and may not be saved, copied, printed, disclosed or used by
>> anyone else.  If you are not the(an) intended recipient,
>> please immediately delete this e-mail from your computer
>> system and notify the sender.  Thank you.
>>
>>
>> ---------------------------------------------------------------------
>> 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]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to