Request for new method.

[Mark Douglas <Ma...@systemsunion.com>]

Hi All,

I would like for a new method to be added to the Category class (along the
lines of the shutdown() method).  The new method 'flush' would be called to
flush the buffers of all appenders in all categories.  This really only
makes sense for SocketAppender and AsyncAppender as the other appenders
don't tend to buffer output (my understanding - possibly incorrect).  Most
appenders would simply return from a call to their flush() method.  The
SocketAppender would call oos.flush() for example.

The reason:
At the moment, the only way to ensure that all Appender output is 'flushed'
is to call Category.shutdown().  This is fine for an app. that is about to
terminate, but for an app. that is continuing, calling Category.shutdown()
means that no further logging takes place.

Why do I want to flush the buffers?
I have some utility code that is used in a number of applications.  After my
code is called, some apps terminate and other do not.  If I call
Category.shutdown() before my code returns, the apps that terminate are
fine, but the others carry on and can't perform further logging (all the
appenders have been deleted).  If I don't call Category.shutdown(), the apps
that terminate lose a few logging messages because they are buffered in the
SocketAppender.

To fix this, my utility code needs to be able to flush the buffers before
returning.  This way, both types of app. would work correctly.  Also, I
don't the apps to have to 'know' about log4j and therefore it would be
unreasonable for them to call Category.shutdown() before they exit.

Ceki,  is it possible to add this functionality for 1.1?  Or is there
something I can do right now to solve this?

Mark Douglas
Systems Union Group

Re: Request for new method.

[Anders Kristensen <ak...@dynamicsoft.com>]

Hi Mark,

The problem you're describing has been discussed previously. It also
applies to FileAppender since buffering was introduced. The main issue
is one of staying compatible with pre-1.3 versions of the JDK, although
as Frank-Olaf points out even then there are cases where the OS buffers
which maybe can't be helped.

So I think an ideal solution would satisfy:

1. The app deals only with generating logging events and shouldn't have
to deal with buffering at all.

2. Buffered Appenders are periodically flushed so that even when there's
a period of no events, previously logged events will eventually make it
to disk (or socket or whatever).

3. On system exit all appenders are flushed.

A solution which uses JDK 1.2 and 1.3 features is

a. add Appender.flush() method
b. address 2) by having buffering Appenders register with a static
method AppenderFlusher.add(Appender) which will periodically flush the
Appender
c. address 3) by registering a hook with Runtime.addShutdownHook(Thread)
which causes the AppenderFlusher to flush everything.

Item b) might use java.util.Timer and TimerTask. These were introduced
with JDK 1.2 but an implementation is available as part of the GNU
classpath project which allows these classes to be used with JDK 1.1.

Item c) on the other hand requires help from the JVM which only became
available with JDK 1.3 and so that's harder. Making flushing of
appenders available through Categories would help I suppose.

Another idea if you're using 1.3 would be for you to write your own
extension of the various Appenders and make them do what's described
above. I've attached a version of the AppenderFlusher class that does b)
- I've been playing around with it to experiment with a solution.

Anders



Mark Douglas wrote:
> 
> Hi All,
> 
> I would like for a new method to be added to the Category class (along the
> lines of the shutdown() method).  The new method 'flush' would be called to
> flush the buffers of all appenders in all categories.  This really only
> makes sense for SocketAppender and AsyncAppender as the other appenders
> don't tend to buffer output (my understanding - possibly incorrect).  Most
> appenders would simply return from a call to their flush() method.  The
> SocketAppender would call oos.flush() for example.
> 
> The reason:
> At the moment, the only way to ensure that all Appender output is 'flushed'
> is to call Category.shutdown().  This is fine for an app. that is about to
> terminate, but for an app. that is continuing, calling Category.shutdown()
> means that no further logging takes place.
> 
> Why do I want to flush the buffers?
> I have some utility code that is used in a number of applications.  After my
> code is called, some apps terminate and other do not.  If I call
> Category.shutdown() before my code returns, the apps that terminate are
> fine, but the others carry on and can't perform further logging (all the
> appenders have been deleted).  If I don't call Category.shutdown(), the apps
> that terminate lose a few logging messages because they are buffered in the
> SocketAppender.
> 
> To fix this, my utility code needs to be able to flush the buffers before
> returning.  This way, both types of app. would work correctly.  Also, I
> don't the apps to have to 'know' about log4j and therefore it would be
> unreasonable for them to call Category.shutdown() before they exit.
> 
> Ceki,  is it possible to add this functionality for 1.1?  Or is there
> something I can do right now to solve this?
> 
> Mark Douglas
> Systems Union Group
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

--
Anders Kristensen

Re: Request for new method.

[Ceki Gülcü <cg...@urbanet.ch>]

At 12:04 01.02.2001 +0000, you wrote:
>Hi All,
>
>I would like for a new method to be added to the Category class (along the
>lines of the shutdown() method).  The new method 'flush' would be called to
>flush the buffers of all appenders in all categories.  This really only
>makes sense for SocketAppender and AsyncAppender as the other appenders
>don't tend to buffer output (my understanding - possibly incorrect).  Most
>appenders would simply return from a call to their flush() method.  The
>SocketAppender would call oos.flush() for example.

Hello Mark,

Flushing the SocketAppender won't help at all. Not one bit. This makes sense because sending depends on the acknowledgement of the other side (the receiving side). Flushing on one side is pretty much useless.  
Closing the SocketAppender is different because the call will not return until all packets in the send buffer are acknowledged or until there is a timeout exception.

What you need to do is to close all appenders (or call Category.shutdown) when your VM exists. Is that a possibility?  Ceki

>The reason:
>At the moment, the only way to ensure that all Appender output is 'flushed'
>is to call Category.shutdown().  This is fine for an app. that is about to
>terminate, but for an app. that is continuing, calling Category.shutdown()
>means that no further logging takes place.
>
>Why do I want to flush the buffers?
>I have some utility code that is used in a number of applications.  After my
>code is called, some apps terminate and other do not.  If I call
>Category.shutdown() before my code returns, the apps that terminate are
>fine, but the others carry on and can't perform further logging (all the
>appenders have been deleted).  If I don't call Category.shutdown(), the apps
>that terminate lose a few logging messages because they are buffered in the
>SocketAppender.
>
>To fix this, my utility code needs to be able to flush the buffers before
>returning.  This way, both types of app. would work correctly.  Also, I
>don't the apps to have to 'know' about log4j and therefore it would be
>unreasonable for them to call Category.shutdown() before they exit.
>
>Ceki,  is it possible to add this functionality for 1.1?  Or is there
>something I can do right now to solve this?
>
>Mark Douglas
>Systems Union Group
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org