logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()
Date Thu, 02 Feb 2017 00:14:51 GMT

    [ 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


Mime
View raw message