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/01/25 10:46:27 UTC

[jira] [Updated] (LOG4J2-1410) Add new LiteTimeoutBlockingWaitStrategy for Async Loggers

     [ https://issues.apache.org/jira/browse/LOG4J2-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remko Popma updated LOG4J2-1410:
--------------------------------
    Fix Version/s:     (was: 2.8)
                   2.8.1

> Add new LiteTimeoutBlockingWaitStrategy for Async Loggers
> ---------------------------------------------------------
>
>                 Key: LOG4J2-1410
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1410
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 2.6
>            Reporter: Remko Popma
>            Assignee: Remko Popma
>             Fix For: 2.8.1
>
>
> Discussion on the Mechanical Sympathy mailing list [brought to light|https://groups.google.com/d/msg/mechanical-sympathy/klefjRqlpQE/0wpjUkE9AwAJ] an interesting aspect of using the Disruptor under light loads: if the background thread has no work to do because the queue is empty, it will block, and await a signal that more work has been put onto the queue.
> Sending this signal is done in the application thread when a new log event is enqueued. This is done by obtaining the shared Lock and calling Condition.signal(). Now, if multiple application threads try to do this signalling at the same time, one of them will be suspended by the OS. This may be costly, and unnecessary, because waking up the background thread twice is wasteful.
> The Disruptor contains the [LiteBlockingWaitStrategy|https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/LiteBlockingWaitStrategy.java] for this.
> Log4j uses the [TimeoutBlockingWaitStrategy|https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/TimeoutBlockingWaitStrategy.java] by default since we had a report of a deadlock with BlockingWaitStrategy on Solaris (LOG4J2-1221).
> This ticket proposes to create a custom wait strategy that combines LiteBlockingWaitStrategy with TimeoutBlockingWaitStrategy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org