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.
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.