This sounds like a good idea, Frank-Olaf :)
I have found another solution which I think I am more happy with (although
it does require JDK 1.3). It also means that default buffering is OK.
My solution is to add a shutdown hook in my utility code that simply calls
Category.shutdown() when the JVM is about to exit. This works a treat :) I
also get the benefit of not relying on application code to tell me to 'tidy
up' on exit.
I have added a static initialiser to my main utility class that looks
something like this:
static
{
Runtime.getRuntime().addShutdownHook(new Thread()
{
public void run() { Category.shutdown(); }
});
}
This guarantees that all the buffering appenders complete before the apps.
terminates. As I said, it does require JDK 1.3, but that's OK for us.
Thanks to everyone for all the input on this :) I am a happy person now ;)
Mark Douglas
Systems Union Group plc
-----Original Message-----
From: Frank-Olaf Lohmann DC [mailto:[EMAIL PROTECTED]]
Sent: 01 February 2001 16:16
To: <Mark Douglas
Cc: [EMAIL PROTECTED]
Subject: Antw: RE: Request for new method.
Mark,
If you want to be on the save side set your send buffer size to 1. Setting
it is not guarantied by Java but I have tested with NT an there it works
fine. Then if you write something to the socket the write is blocked until
your data is send or you get an exception (timeout by the OS). If you call
close in the same thread you are on the save side now. If you get an
exception you have to decide what to do with your unsent message.
Be aware of usage of multiple writes in a loop for only one message. With
buffer size set to one you really send one package after the other each
acknowledged over the wire first. writeObject() that is used in
SocketAppender has this drawback. Now you are more secure for the price of
degrade in link performance. To solve this drawback it is a good idea to use
a buffered stream in front of the socket stream and use the flush that now
do what we expect.
Kind regards
Frank-Olaf Lohmann
>>> Mark Douglas <[EMAIL PROTECTED]> 01.02.2001 14.17 Uhr >>>
Hi Ceki,
I could get all apps to call into my utility code before they exit, but I
was kind of hoping that I could 'hide' the fact that I was using log4j.
It's a shame there are no destructors as in C++ ;-)
I've had a quick play with trying to flush the Socket, but you are calling
oos.flush() anyway in the SocketAppender.append() method.
I have even tries playing with the SO_LINGER option on the socket, and that
seemed to have no effect.
Looks like the only thing that works is calling Category.shutdown().
Sorry if this topic has been discussed before, but I'm fairly new to this
forum.
Thanks to everyone for all the feedback :)
Mark Douglas
Systems Union Group plc
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: 01 February 2001 13:22
To: LOG4J Developers Mailing List
Subject: Re: Request for new method.
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: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
