Mailing-List: contact log4j-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Users List" <log4j-user@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: log4j: dump wrap-around buffer of all log messages
Date: Mon, 11 Aug 2003 09:48:29 -0400
Message-ID: <9C5166762F311146951505C6790A9CF8A6E9C2@US-VS1.corp.mpi.com>
Thread-Topic: log4j: dump wrap-around buffer of all log messages
Thread-Index: AcNgDFBaVFzZS9iQTl24mR634q3B9AAABM9AAABdVDAAADtmcA==
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Log4J Users List" <log4j-user@jakarta.apache.org>


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 memor=
y
>usage just 16k*size of a logged message. Of course if your code if fu=
ll of
>debug logging, then the program will be slow, but on the other hand w=
ill
>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.  Se=
condly, that amount might be multiplied many times by having a separat=
e 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 run=
time.  I will not accept a system that always keeps an extra 16k messa=
ges in case there's an error.

I'm not saying this feature is a completely bad idea.  It can be usefu=
l 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, co=
mplaining of the other package's performance, and then asks to add a f=
eature that seems like a performance hog to log4j, that's a red flag f=
or me.

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

Yoav Shapira


>
>> -----Original Message-----
>> From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
>> 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=FClc=FC [mailto:ceki@qos.ch]
>> >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 simil=
ar
>> >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 Tra=
ce
>> >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-aro=
und
>> >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: log4j-user-unsubscribe@jakarta.apache.org=

>> >>For additional commands, e-mail: log4j-user-help@jakarta.apache.o=
rg
>> >
>> >--
>> >Ceki For log4j documentation consider "The complete log4j manual"
>> >      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>> >
>> >
>> >
>> >
>> >------------------------------------------------------------------=
---
>> >To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>> >For additional commands, e-mail: log4j-user-help@jakarta.apache.or=
g
>>
>>
>>
>>
>> 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: log4j-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-user-help@jakarta.apache.org=

>>
>>
>
>---------------------------------------------------------------------=

>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org


This e-mail, including any attachments, is a confidential business com=
munication, and may contain information that is confidential, propriet=
ary and/or privileged.  This e-mail is intended only for the individua=
l(s) to whom it is addressed, and may not be saved, copied, printed, d=
isclosed or used by anyone else.  If you are not the(an) intended reci=
pient, please immediately delete this e-mail from your computer system=
 and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org