[
https://issues.apache.org/jira/browse/LOG4J2-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522488#comment-17522488
]
Matt Sicker commented on LOG4J2-3472:
-------------------------------------
Depending on how immediately you need this feature, I've been considering
porting the DI system in 3.x to 2.x (for 2.18.0 at the current state). Without
using DI, though, I'd probably lean toward option 1 as similar to how I made
the particular BlockingQueue class to use in an async appender configurable.
The factories should be easy to migrate to DI as well which is nice.
> 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)
