AsyncAppender features...

[Niclas Hedhman <ni...@ewarna.com>]

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.

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.


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.

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


Niclas Hedhman





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: AsyncAppender features...

[Scott Farquhar <sc...@atlassian.com>]

Whilst you are waiting for people to decide on this - can I suggest that 
you go ahead an create a new Appender that works to your specifications. 
  You call this something new - eg. TailDropAsyncAppender.

I am not sure if dropping log-lines is what people would like, but while 
they are deciding, you can always use your version of the code.  Feel 
free to contribute it - there are many user contributions under /contribs.

Cheers,
Scott

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.
> 
> 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.
> 
> 
> 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.
> 
> I know I have no votes, but -1 on that anyway...
> 
> 
> Niclas Hedhman
> 
> 
> 
> 
> 
> -- 
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


-- 
Scott Farquhar :: scott@atlassian.com

Atlassian :: http://www.atlassian.com
      Supporting YOUR J2EE World


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: AsyncAppender features...

[Niclas Hedhman <ni...@ewarna.com>]

Don't misunderstand me, I think Log4J is one of the greatest and most 
essential Java library I have ever come across, both rich in features, 
robust, fast and especially easy to use. All the highest ranking credit 
to the people involved.


About dropping messages in the AsyncAppender...
You are very cautious about message loss, where I am more cautious about 
speed impact if the buffer is filled, either by large amounts of data in 
the continous stream of logging information (which per se is probably a 
bad configuration in a production environment) or bursts of logging 
messages due to intermittent spikes in throughput.

Either way, increasing the buffer size can not always solve the "out of 
fifo" scenario, and I am suggesting some mechanism that let me, in 
runtime, bypass the wait for the write-out of the log messages. If I 
don't specify any rules or if the buffer can not be empties according to 
my rules, it will still wait for the secondary appender to pick a 
message up. Just suggestion some more flexibility to avoid "bottleneck" 
scenarios.

Please note that I am suggesting that the default behaviour is the 
current model. Also, there is no speed impact for non-full situations, 
as the check for the Fifo size is already required.

Exactly what "rule system" to use is less of my concern, perhaps even 
greater to have a hook for it, that the AsyncAppender will delegate to 
if the situation arises. I now believe such a Delegation is a very 
powerful approach, and rather easy to implement.

public interface FifoFullHandler
{
    void initialize( AsyncAppender appender );

    destroy();

    BoundedFIFO bufferFull( BoundedFIFO buffer );
}

The initialize and destroy methods are perhaps superflous, but I have 
such a habbit to ensure proper interface contract and clean up procedures.

In the AsyncAppender, there will be;

if( bf.isFull() )
{
    if( fifoFullHandler == null )
    {
        // wait as today
        while( bf.isFull() )
            wait();
    }
    else
        bf = fifoFullHandler.bufferFull( bf );
}

(synchronization emitted for clarity)
the if() statement is executing the same speed as the current while() 
statement. Meaning, typically no speed penalty, which I think is acceptable.

The BoundedFIFO needs some additional methods for removal of events, OR 
that a FIFO interface is introduced and BoundedFIFO is the default 
implementation.


Well, this is my 2cents worth. Any further input is appreciated, and 
I'll probably go ahead and make it happen after my honeymoon next week.

Cheers....
Niclas


Ceki Gülcü wrote:

> 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
> loss.
>
> 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:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: AsyncAppender features...

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

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
loss.

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>