[
https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849157#comment-15849157
]
Remko Popma commented on LOG4J2-1760:
-------------------------------------
Thanks for the clarification. I looked at the code and I agree there is a
problem: in the current code when {{tryTransfer}} fails (because the
background thread is busy with the previous event), the current event will be
delegated to the {{AsyncQueueFullPolicy}}. The default policy bypasses the
queue and appends directly to the underlying appender.
This can be improved. As an alternative, when {{tryTransfer}} returns true,
AsyncAppender could inspect the queue size and only delegate to the
AsyncQueueFullPolicy when the size exceeds the configured max, otherwise
enqueue the event with {{offer}}. I need to check the semantics for
LinkedTransferQueue::size, some imprecision is acceptable but performance
impact is not.
Meanwhile, you can work around the issue by configuring the
AsyncQueueFullPolicy to enqueue the event: set system property
{{log4j2.AsyncQueueFullPolicy}} to {{Discard}} and set
{{log4j2.DiscardThreshold}} to a value that doesn't discard any events. (Away
from pc, don't remember if it's ALL or NONE.)
> AsyncAppender with LinkedTransferQueue.offer()
> ----------------------------------------------
>
> Key: LOG4J2-1760
> URL: https://issues.apache.org/jira/browse/LOG4J2-1760
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
> Affects Versions: 2.7
> Reporter: Addison Walterson
> Priority: Minor
>
> I suggest that the AsyncAppender can use a LinkedTransferQueue for which
> offer() is used to enqueue messages because tryTransfer() only succeeds if
> the receiving thread waits for a message which means that the queue has
> length 0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
