[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 ] Ralph Goers updated LOG4J2-1410: Fix Version/s: (was: 2.8.1) 2.8.2 > 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.2 > > > 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.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[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.7) 2.8 > 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 > > > 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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[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:
Description:
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.
was:
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.
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
