[
https://issues.apache.org/jira/browse/LOG4J2-2858?focusedWorklogId=439053&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-439053
]
ASF GitHub Bot logged work on LOG4J2-2858:
------------------------------------------
Author: ASF GitHub Bot
Created on: 30/May/20 11:14
Start Date: 30/May/20 11:14
Worklog Time Spent: 10m
Work Description: stepan2271 edited a comment on pull request #361:
URL: https://github.com/apache/logging-log4j2/pull/361#issuecomment-636316106
> I put some comments on the mechanics of the proposed changes, but I
actually have a bigger question:
>
> what problem are we trying to solve?
> Can you explain the use case where it would help to be able to fine-tune
sleep time and number of retries?
What I want to achieve is to log messages with low resource consumption and
at the same time garbage free (since I have low latency code in the same JVM
with no gc pauses allowed). Currently, I dont see an option that satisfies
these requeirements. If I use BlockingWaitStrategy or
TimeoutBlockingWaitStrategy then I have garbage. If I use SleepingWaitStrategy
with default parameters, YieldingWaitStrategy or BusyspinWaitStrategy then
logging consumes resources that I don`t want to allocate there.
If you have any other suggestions on how to handle my use case, I would be
happy to use your approach.
----------------------------------------------------------------
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: 439053)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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)
