[
https://issues.apache.org/jira/browse/LOG4J2-2858?focusedWorklogId=439153&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-439153
]
ASF GitHub Bot logged work on LOG4J2-2858:
------------------------------------------
Author: ASF GitHub Bot
Created on: 30/May/20 22:10
Start Date: 30/May/20 22:10
Worklog Time Spent: 10m
Work Description: remkop commented on pull request #361:
URL: https://github.com/apache/logging-log4j2/pull/361#issuecomment-636391507
Thanks for making those changes.
The system properties used in Log4j2 are documented in this section in the
Configuration page of the manual:
https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/configuration.adoc#system-properties
Please document the additional system properties for both the `AsyncLogger`
prefix and the `AsyncLoggerConfig` prefix, to follow the convention of the
existing docs.
----------------------------------------------------------------
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: 439153)
Time Spent: 1h 50m (was: 1h 40m)
> 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 50m
> 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)
