You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2017/02/02 00:14:51 UTC
[jira] [Comment Edited] (LOG4J2-1760) AsyncAppender with
LinkedTransferQueue.offer()
[ https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849157#comment-15849157 ]
Remko Popma edited comment on LOG4J2-1760 at 2/2/17 12:14 AM:
--------------------------------------------------------------
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. Effectively the queue size is zero.
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.)
was (Author: remkop@yahoo.com):
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org