[
https://issues.apache.org/jira/browse/LOG4J2-2858?focusedWorklogId=439057&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-439057
]
ASF GitHub Bot logged work on LOG4J2-2858:
------------------------------------------
Author: ASF GitHub Bot
Created on: 30/May/20 11:34
Start Date: 30/May/20 11:34
Worklog Time Spent: 10m
Work Description: remkop commented on pull request #361:
URL: https://github.com/apache/logging-log4j2/pull/361#issuecomment-636318316
Understood, thanks for the clarification!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 439057)
Time Spent: 1h (was: 50m)
> More flexible configuration of WaitStrategy of Disruptor
> --------------------------------------------------------
>
> Key: LOG4J2-2858
> URL: https://issues.apache.org/jira/browse/LOG4J2-2858
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.13.3
> Reporter: Stepan Gorban
> Priority: Minor
> Fix For: 2.13.3
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I have realized that there is garbage generated from the following stack
> trace:
> {code:java}
> AbstractQueuedSynchronizer$Node
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter()
>
> long
> util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long)
> long com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(long, Sequence,
> Sequence, SequenceBarrier)
> long com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(long)
> void com.lmax.disruptor.BatchEventProcessor.processEvents()
> void com.lmax.disruptor.BatchEventProcessor.run()
> void java.lang.Thread.run()
> {code}
> Thus, I would like to use some other wait strategy. However there are only
> few possibilities. I would prefer to use SleepingWaitStrategy with custom
> parameters. But there is no such option:
> {color:#000080}case {color}{color:#008000}"SLEEP"{color}:
> {color:#000080}return new {color}SleepingWaitStrategy();
> {color:#000080}case {color}{color:#008000}"YIELD"{color}:
> {color:#000080}return new {color}YieldingWaitStrategy();
> {color:#000080}case {color}{color:#008000}"BLOCK"{color}:
> {color:#000080}return new {color}BlockingWaitStrategy();
> {color:#000080}case {color}{color:#008000}"BUSYSPIN"{color}:
> {color:#000080}return new {color}BusySpinWaitStrategy();
> {color:#000080}case {color}{color:#008000}"TIMEOUT"{color}:
> {color:#000080}return new {color}TimeoutBlockingWaitStrategy(timeoutMillis,
> TimeUnit.{color:#660e7a}MILLISECONDS{color});
> {color:#000080}default{color}:
> {color:#000080}return new {color}TimeoutBlockingWaitStrategy(timeoutMillis,
> TimeUnit.{color:#660e7a}MILLISECONDS{color});
>
> The key goal is to log messages with weak requirements on logging latency,
> BUT in the JVM with low-latency code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
