Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Thu, 2 Feb 2017 00:14:51 +0000 (UTC)
From: "Remko Popma (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.13031424.1483288747000.12821.1485994491596@Atlassian.JIRA>
In-Reply-To: <JIRA.13031424.1483288747000@Atlassian.JIRA>
References: <JIRA.13031424.1483288747000@Atlassian.JIRA> <JIRA.13031424.1483288747491@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (LOG4J2-1760) AsyncAppender with
 LinkedTransferQueue.offer()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 02 Feb 2017 00:15:01 -0000


    [ 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