[
https://issues.apache.org/jira/browse/LOG4J2-2858?focusedWorklogId=455738&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-455738
]
ASF GitHub Bot logged work on LOG4J2-2858:
------------------------------------------
Author: ASF GitHub Bot
Created on: 07/Jul/20 21:57
Start Date: 07/Jul/20 21:57
Worklog Time Spent: 10m
Work Description: carterkozak commented on a change in pull request #361:
URL: https://github.com/apache/logging-log4j2/pull/361#discussion_r451167275
##########
File path:
log4j-core/src/main/java/org/apache/logging/log4j/core/async/DisruptorUtil.java
##########
@@ -60,36 +60,46 @@
private DisruptorUtil() {
}
- static long getTimeout(final String propertyName, final long
defaultTimeout) {
- return PropertiesUtil.getProperties().getLongProperty(propertyName,
defaultTimeout);
+ static WaitStrategy createWaitStrategy(final String propertyName) {
+ final String strategy =
PropertiesUtil.getProperties().getStringProperty(propertyName, "Timeout");
+ LOGGER.trace("property {}={}", propertyName, strategy);
+ final String strategyUp = Strings.toRootUpperCase(strategy);
+ final long timeoutMillis = parseAdditionalLongProperty(propertyName,
"Timeout", 10L);
+ // String (not enum) is deliberately used here to avoid
IllegalArgumentException being thrown. In case of
+ // incorrect property value, default WaitStrategy is created.
+ switch (strategyUp) {
+ case "SLEEP":
+ final long sleepTimeNs =
+ parseAdditionalLongProperty(propertyName,
"SleepTimeNs", 100L);
+ final String key = getFullPropertyKey(propertyName, "Retries");
+ final int retries =
+ PropertiesUtil.getProperties().getIntegerProperty(key,
200);
+ return new SleepingWaitStrategy(retries, sleepTimeNs);
+ case "YIELD":
+ return new YieldingWaitStrategy();
+ case "BLOCK":
+ return new BlockingWaitStrategy();
+ case "BUSYSPIN":
+ return new BusySpinWaitStrategy();
+ case "TIMEOUT":
+ return new TimeoutBlockingWaitStrategy(timeoutMillis,
TimeUnit.MILLISECONDS);
+ default:
+ return new TimeoutBlockingWaitStrategy(timeoutMillis,
TimeUnit.MILLISECONDS);
+ }
Review comment:
At some point we could allow custom WaitStrategy implementations to be
provided, likely most helpful for demonstrating changes like this without
waiting a full release cycle. This change doesn't make it any more difficult to
implement later on, and in the majority of cases we use simple configurations
without custom code. :+1:
----------------------------------------------------------------
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: 455738)
Time Spent: 3h 10m (was: 3h)
> 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 10m
> 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)
