[
https://issues.apache.org/jira/browse/LOG4J2-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159479#comment-17159479
]
ASF subversion and git services commented on LOG4J2-2858:
---------------------------------------------------------
Commit 8e152dfd53a75a5c112424d98bc049a6b6b08725 in logging-log4j2's branch
refs/heads/master from stepan2271
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8e152df ]
LOG4J2-2858: More flexible configuration of WaitStrategy of Disruptor (#361)
Added additional properties for setting sleepTimeNs and retries parameters of
SleepingWaitStrategy
> 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: 3h 20m
> 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)
