There is also a CyclicBufferList class within the org.apache.log4j.chainsaw
package that is used by Chainsaw.  It's an (re(re)implementation of Ceki's
fine CyclicBuffer class, but was changed around to implement the
java.util.List interface for Collection-style goodness.  This is available
from CVS HEAD, if anyone is interested.

> -----Original Message-----
> From: Alan Brown [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 12 May 2004 2:36 AM
> To: Log4J Users List
> Subject: RE: flush buffer on error
> 
> 
> Someone correct me if I'm wrong but...
> 
> I believe that the CyclicBuffer class is your friend.  
> However, it doesn't seem to be used in many of the Appender 
> classes (SMTPAppender uses it, but I'm not sure any of the 
> others does).  You may need to subclass RollingFileAppender 
> (if that's the appender you're using) and have it implement 
> the cyclic buffer paradigm.  Check the SMTPAppender source to 
> see how it's done.
> 
> alan
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, May 11, 2004 1:25 AM
> To: [EMAIL PROTECTED]
> Subject: flush buffer on error
> 
> 
> 
> 
> 
> Hello all,
> 
> just a little question to a logging architecture I would prefer.
> For my production environment I would like to write all log 
> messages (for
> all log levels)
> into a buffer (memory, queue, whatever).
> May be a ring buffer of 5 buffers.
> If everything runs well I just write the warn messages of the 
> last buffer
> into a file
> and drop the rest.
> But if somewhere in the log an error or even a fatal error happens,
> then I would like to know what exactly happened before this error.
> So in this case I would write all the messages in the ring 
> buffer into a
> file.
> I hope this would be not too bad in the viewpoint of performance
> as the whole messages are only stored in the working memory (heap).
> 
> I have searched around, but I did not find this architectural 
> approach.
> But may be it exists and I just did not see.
> 
> So please tell me if some of you know where to find such an 
> implementation.
> Is this available with log4j?
> Or if you know good arguments against this approach, please tell me.
> 
> Thanks in advance
> 
> herb
> 
> --
> Diese E-Mail enth�lt vertrauliche und/oder rechtlich gesch�tzte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder 
> diese E-Mail
> irrt�mlich erhalten haben, informieren Sie bitte sofort den 
> Absender und
> vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie 
> die unbefugte
> Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht 
> gestattet.
> 
> Wir haben alle verkehrs�blichen Ma�nahmen unternommen, um das 
> Risiko der
> Verbreitung virenbefallener Software oder E-Mails zu 
> minimieren, dennoch
> raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle 
> Anh�nge an dieser
> Nachricht durchzuf�hren. Wir schlie�en au�er f�r den Fall von 
> Vorsatz oder
> grober Fahrl�ssigkeit die Haftung f�r jeglichen Verlust oder 
> Sch�den durch
> virenbefallene Software oder E-Mails aus.
> 
> Jede von der Bank versendete E-Mail ist sorgf�ltig erstellt 
> worden, dennoch
> schlie�en wir die rechtliche Verbindlichkeit aus; sie kann 
> nicht zu einer
> irgendwie gearteten Verpflichtung zu Lasten der Bank ausgelegt werden.
> ______________________________________________________________________
> 
> This e-mail may contain confidential and/or privileged 
> information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of  the 
> material in this
> e-mail or of parts hereof is strictly forbidden.
> 
> We have taken precautions to minimize the risk of 
> transmitting software
> viruses but nevertheless advise you to carry out your own 
> virus checks on
> any attachment of this message. We accept no liability for 
> loss or damage
> caused by software viruses except in case of gross negligence 
> or willful
> behaviour.
> 
> Any e-mail messages from the Bank are sent in good faith, but 
> shall not be
> binding or construed as constituting any kind of obligation 
> on the part of
> the Bank.
> 
> 
> ---------------------------------------------------------------------
> 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]
> 

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

Reply via email to