Ceki,
I think it will work but I think this reinvent the wheel. TCP do this already. See
also comment to Mark, set buffer size ...
I only don't know whether this works on all OS.
Kind regards
Frank-Olaf Lohmann
>>> Ceki Gülcü <[EMAIL PROTECTED]> 01.02.2001 14.47 Uhr >>>
Mark,
One thing you can try is to implement your own application level ack. So instead of
sending, sending, ..., sending, you send, wait for ack, send, wait for ack, ...., send
wait for ack.
For example the socket appender would need to be modified as follows:
public
void append(LoggingEvent event) {
.. removed stuff
try {
oos.writeObject(event);
ois.readInt();
....
} catch (...) {
...
}
SocketNode would need to be changed to:
public void run() {
LoggingEvent event;
... removed stuff
try {
while(true) {
event = (LoggingEvent) ois.readObject();
oos.writeInt(counter++);
remoteCategory = hierarchy.getInstance(event.categoryName);
event.category = remoteCategory;
if(event.priority.isGreaterOrEqual(remoteCategory.getChainedPriority())) {
remoteCategory.callAppenders(event);
}
}
}
...
}
You get the idea. This will solve your persistence problem but might slow things down
quite a bit. Just an idea. Ceki
At 14:24 01.02.2001 +0000, you wrote:
>Hi Anders,
>
>Thanks for the feedback :)
>
>One thing I have learned today: Flushing a Socket does not actually wait for
>all buffered data to be sent.
>
>This is proved as the current implementation of SocketAppender calls flush
>on the Socket in each append() call. Yet logging events are lost when the
>app terminates unless the Category.shutdown() method is called.
>
>This means that using a thread (or other method) to periodically flush the
>appender would not help a SocketAppender.
>
>Mark Douglas
>Systems Union Group plc
>
>-----Original Message-----
>From: Anders Kristensen [mailto:[EMAIL PROTECTED]]
>Sent: 01 February 2001 13:32
>To: LOG4J Developers Mailing List
>Subject: Re: Request for new method.
>
>
>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: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>--
>Anders Kristensen
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
----
Ceki Gülcü - Independent IT Consultant
av. de Rumine 5 Tel: ++41 21 351 23 15
CH-1005 Lausanne e-mail: [EMAIL PROTECTED] or
Switzerland [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]
