[
https://issues.apache.org/jira/browse/LOG4J2-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14632502#comment-14632502
]
Remko Popma commented on LOG4J2-1080:
-------------------------------------
I looked at the patch and understand what you are trying to do.
One thing to bear in mind is that any solution along these lines should include
both AsyncLogger/AsyncConfigHelper and AsyncAppender since they are
conceptually similar. (Also, a full solution should document how users can
control this feature and ideally include unit tests.)
Another alternative that is perhaps more generic is to support something
similar to Logback's
[discardingThreshold|http://logback.qos.ch/manual/appenders.html#asyncDiscardingThreshold].
The idea behind the discarding threshold is that an almost (80%) full queue is
a sign that an appender is not keeping up, and to prevent the application from
slowing down because of this, only important log events (WARN, ERROR and FATAL)
are added to the queue. Other events (TRACE, DEBUG, INFO) are dropped. The
discarding threshold is configurable, so it could be set to discard all events
if the queue is 80% full, or discard nothing if you want to disable this
feature.
(On a personal note, I originally did not like the discardingThreshold feature
since it was touted as a way to improve logging performance in general. I
disagree with this. However, I've recently come around to the idea that it is a
useful mechanism to deal with slow appenders.)
> Drop events when the RingBuffer is full
> ---------------------------------------
>
> Key: LOG4J2-1080
> URL: https://issues.apache.org/jira/browse/LOG4J2-1080
> Project: Log4j 2
> Issue Type: New Feature
> Reporter: tzachi
> Attachments: AsyncLogger.dropEvents.patch
>
>
> I am running into performance issue with an appender, in a certain scenario
> (attached at the bottom), that causes RingBuffer to reach its full capacity.
> When that happens I can see that my app throughput drops significantly.
> I think it will be really useful to be able to configure the RingBuffer
> handler to be able to drop events whenever the buffer reaches its capacity,
> instead of what seems currently as blocking, as I don't want the logging to
> affect the main application.
> ---------------------------------------------------------------------
> Here is the scenario that led me to this request:
> I am currently testing the log4j-flume-ng appender and running into some
> issues. It seems like whenever log4j appender fails to log an event it causes
> the disruptor ring buffer to get full which slows down the whole system.
> My setup looks more or less like that:
> process 1: Java app which uses log4j2 (with flume-ng’s Avro appender)
> process 2: local flume-ng which gets the logs on using an Avro source and
> process them
> Here are my findings:
> When Flume (process 2) is up and running, everything actually looks really
> good. The ring buffer capacity is almost always full and there are no
> performance issues. The problem starts when I shut down process 2 - I am
> trying to simulate a case in which this process crashes, as I do not want it
> to effect process 1. As soon as I shut down flume I start getting exceptions
> produced by log4j telling me they cannot append the log - so far it makes
> sense. The thing is, that at the same time I can see that the ring buffer
> starts to fill up. As long as it’s not totally full process’s 1 throughput
> stays the same. The problem gets serious as soon as the buffer reaches full
> capacity. When that happens the throughput drops in 80% and it does not seem
> to recover from this state. But, as soon as I restart process 2, things get
> back to normal pretty quick - the buffer gets emptied, and the throughput
> climbs back to what it was before. I assume that from some reason a fail to
> append makes the RingBuffer consumer thread significantly slower.
> Besides checking why the flume appender preform slower when an exception is
> thrown, I wish I could just discard the log events when the buffer gets full.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
