logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: AsyncAppender features...
Date Tue, 05 Mar 2002 23:25:09 GMT
At 11:00 05.03.2002 +0800, Niclas Hedhman wrote:

>I have posted this same issue when I first joined the mailing list, but 
>never saw it show up, so...
>The AsyncAppender is a great feature for slow logging devices, such as 
>file and sockets, but if you have too much load the async FIFO buffer will 
>wait (or so it seems) for the secondary appender to complete (i.e. remove 
>entries). And then the system will come to a grinding halt anyway.

Hi Niclas,

Your description is not exactly flattering but it is fair nonetheless.

>My suggestion is to introduce a small feature in the AsyncAppender. It 
>works like this;
>If the FIFO buffer is full, the AsyncAppender first try to remove all 
>statements of a certain level (and higher/lower?) in the FIFO, place a 
>marker in the FIFO that it has occurred, and add the new entry. If no 
>entries were removed, no marker is inserted and current behaviour prevails.
>"none" should be the default level for removal and the current behaviour.

You are essentially suggesting to drop messages. What will happen when all 
remaining messages in the buffer
are of high priority? What will you drop then? What is a high priority 
message? 128 identical ERROR messages do not
convey more information than a single ERROR messages accompanied with the 
surrounding WARN, INFO and
DEBUG messages. I am uncomfortable with dropping message based on what 
seems to be inappropriate criteria.

One interesting approach would be to automatically enlarge the 
AsyncAppender buffer. I further believe that this larger
buffer must be both local and persistent, i.e. on local disk, because a 
memory based large buffer would be highly vulnerable to

The topic is quite interesting although I am afraid it is a particular case 
of a general distributed computing problem.

>I have seen other requests for having the "Location" information available 
>for AsyncBuffers, but I think this is less desirable. The rationale is 
>that in a development environment, you don't use the AsyncAppender, and in 
>the production evironment, the Location generation takes too long to 
>generate anyway, and the primary feature of the AsyncAppender (low 
>latency) is lost.

The location information *is* available from the AsyncAppender. It's there 
for those who want to use it although it is turned off by default.

>I know I have no votes, but -1 on that anyway...

You're vote is cast about a year too late. By the way, you do not have to 
be a committer to
cast a vote. Your vote won't "officially" count but it will count nonetheless.

Ceki Gülcü

To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

View raw message