[
https://issues.apache.org/jira/browse/LOG4J2-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-3472:
--------------------------------
Description:
See also LOG4J2-2858.
Currently Log4j allows a fixed set of disruptor WaitStrategies to be
configured. The current code has two drawbacks:
* the fixed set does not include all built-in WaitStrategies that the
disruptor library provides
* the configuration does not allow custom implementations of the
{{com.lmax.disruptor.WaitStrategy}} interface.
h4. Proposal:
Introduce a {{org.apache.logging.log4j.core.async.WaitStrategyProvider}}
interface. Users may configure instances of this interface by setting system
property {{log4j2.asyncWaitStrategyProvider}}.
Proposed implementation is to modify {{DisruptorUtil::createWaitStrategy}} to
check for the existence of this system property, before doing anything else. If
this property exists and a class can be instantiated based on the value of this
property, and the resulting WaitStrategyProvider instance provides a non-null
{{com.lmax.disruptor.WaitStrategy}} instance, then this waitstrategy is
returned from {{DisruptorUtil::createWaitStrategy}}. Otherwise, we fall back
to the existing logic.
Note that for simplicity I do not propose to have separate system properties
for Async Loggers and Async LoggerConfigs.
was:
See also LOG4J2-2858.
Currently Log4j allows a fixed set of disruptor WaitStrategies to be
configured. The current code has two drawbacks:
* the fixed set does not include all built-in WaitStrategies that the
disruptor library provides
* the configuration does not allow custom implementations of the
{{com.lmax.disruptor.WaitStrategy}} interface.
h4. Proposal:
Introduce a {{org.apache.logging.log4j.core.async.WaitStrategyProvider}}
interface. Users may configure instances of this interface by setting system
property {{log4j2.asyncWaitStrategyProvider}}.
Proposed implementation is to modify {{DisruptorUtil::createWaitStrategy}} to
check for the existence of this system property, before doing anything else. If
this property exists and a class can be instantiated based on the value of this
property, and the resulting instance provides a non-null
{{com.lmax.disruptor.WaitStrategy}} instance, then this waitstrategy is
returned from {{DisruptorUtil::createWaitStrategy}}. Otherwise, we fall back
to the existing logic.
Note that for simplicity I do not propose to have separate system properties
for Async Loggers and Async LoggerConfigs.
> Allow configuration of custom Disruptor WaitStrategy
> ----------------------------------------------------
>
> Key: LOG4J2-3472
> URL: https://issues.apache.org/jira/browse/LOG4J2-3472
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configuration, Core
> Affects Versions: 2.17.2
> Reporter: Remko Popma
> Assignee: Remko Popma
> Priority: Major
> Fix For: 2.17.3
>
>
> See also LOG4J2-2858.
> Currently Log4j allows a fixed set of disruptor WaitStrategies to be
> configured. The current code has two drawbacks:
> * the fixed set does not include all built-in WaitStrategies that the
> disruptor library provides
> * the configuration does not allow custom implementations of the
> {{com.lmax.disruptor.WaitStrategy}} interface.
> h4. Proposal:
> Introduce a {{org.apache.logging.log4j.core.async.WaitStrategyProvider}}
> interface. Users may configure instances of this interface by setting system
> property {{log4j2.asyncWaitStrategyProvider}}.
> Proposed implementation is to modify {{DisruptorUtil::createWaitStrategy}} to
> check for the existence of this system property, before doing anything else.
> If this property exists and a class can be instantiated based on the value of
> this property, and the resulting WaitStrategyProvider instance provides a
> non-null {{com.lmax.disruptor.WaitStrategy}} instance, then this waitstrategy
> is returned from {{DisruptorUtil::createWaitStrategy}}. Otherwise, we fall
> back to the existing logic.
> Note that for simplicity I do not propose to have separate system properties
> for Async Loggers and Async LoggerConfigs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
