Remko Popma created LOG4J2-1410:
-----------------------------------
Summary: 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.7
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: [email protected]
For additional commands, e-mail: [email protected]
