Request: flushAll() method on loggers for writer appenders

[Barak Simon <ba...@db.com>]

Hello,
Would it be possible to add a flushAll() method on the logger & appender interfaces that will trigger an immediate flush of the ostreams of the WriterAppender derived classes?

Reason we need it, is we have a very demanding application which need to use the BufferedIO/ImmediateFlush pair for gaining performance,
but at some stage (when getting a specific signal) we would also like to be able to flush whatever is currently in the buffers
(without changing the flags)

The only way I know of doing it non-intrusively at present is:
1. Iterating on all the appenders on the logger's hierarchy.
2. Setting the BufferedIO/ImmediateFlush to false/true respectively.
3. Sending a "Flushing All"  bogus message.
4. Reverting flags to what they were before by re-iterating on appenders.

Which, needless to say, is less than elegant solution...

Implementing it as part of log4cxx (and/or log4j?!) seems much simpler and cleaner.

Thanks,
Please let me know what you think,
Barak
________________________
Barak Simon
GED IT Core Platform
Deutsche Bank
190 George St. Sydney, 2000
Phone: +61 2 925 85070
Fax:   +61 2 925 95050



--

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 unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Re: Request: flushAll() method on loggers for writer appenders

[Curt Arnold <ca...@apache.org>]

I did see your earlier message and thought that I had replied to it, 
but can't seem to find a message in the archives.

I'd like to get Ceki's opinion on this.  I can see where it would be 
useful to you, but I'm sure that there are probably issues that need to 
be considered.

The appropriate location for the call, putting it on the appender isn't 
very handy.  Maybe Logger.flush() and LoggerRepository.flushAll()?

What guarantees do you want after the return from flush/flushAll()?  
Should a network or async appender block until its queue is empty?   Or 
do you just want to just hint that it would be a good time to flush 
buffers?

What happens to if a log request is made during the execution of 
flush(), should it block until completion and be done after the flush 
is complete?

If we can work through the issues, would you be willing to submit 
patches to log4j and log4cxx?

If you'd like to take the question to the log4j-dev mailing list (which 
I subscribe to), you might get more lively discussion.

Re: Request: flushAll() method on loggers for writer appenders

[Ceki Gülcü <ce...@qos.ch>]

Hello Barak, Curt,

Since only WriterAppender and derived classes are concerned, it seems
to me that only WriterAppender should be modified by adding a flush()
method. Assuming the notifier has access to the WriterAppender
instance, it can invoke its flush() method whenever it feels
necessary. (The flush() method should be synchronized exactly in the
same way the doAppend method is synchronized.)

Given the nature of this demand and unless I am missing something,
modifying Logger or LoggerRepository does not seem reasonable.


At 06:48 AM 12/21/2004, Barak Simon wrote:
>Hello,
>Would it be possible to add a flushAll() method on the logger & appender 
>interfaces that will trigger an immediate flush of the ostreams of the 
>WriterAppender derived classes?
>
>Reason we need it, is we have a very demanding application which need to 
>use the BufferedIO/ImmediateFlush pair for gaining performance,
>but at some stage (when getting a specific signal) we would also like to 
>be able to flush whatever is currently in the buffers
>(without changing the flags)
>
>The only way I know of doing it non-intrusively at present is:
>1. Iterating on all the appenders on the logger's hierarchy.
>2. Setting the BufferedIO/ImmediateFlush to false/true respectively.
>3. Sending a "Flushing All"  bogus message.
>4. Reverting flags to what they were before by re-iterating on appenders.
>
>Which, needless to say, is less than elegant solution...
>
>Implementing it as part of log4cxx (and/or log4j?!) seems much simpler and 
>cleaner.
>
>Thanks,
>Please let me know what you think,
>Barak

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/