Dropwizard loglog async log rotation, вызывающий ожидание потоков приложений

Question

Потоки приложений застревают всякий раз, когда файл журнала вращается, это вызывает всплеск задержки API Я использую Async Appender, не уверен, почему во время ротации потоки приложений ожидание.

logback.xml

<configuration debug="true"> 
<property name="async.discardingThreshold" value="0"/> 
<property name="async.queueSize" value="500"/> 
<property name="log.dir" value="/var/log"/> 
<property name="log.pattern" value="%highlight(%-5level) [%date] [%thread] [%X{id}] [%cyan(%logger{0})]: %message%n"/> 
<property name="errorLog.pattern" value="%highlight(%-5level) [%date] [%thread] [%X{id}] [%red(%logger{0})]: %message%n"/> 
<property name="log.maxHistory" value="200"/> 
<property name="log.default.maxFileSize" value="100MB"/> 
<property name="log.error.maxFileSize" value="10MB"/> 


<appender name="INFO" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
    <File>${log.dir}/default.log</File> 
    <Append>true</Append> 
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> 
     <fileNamePattern>${log.dir}/default.%i.log.gz</fileNamePattern> 
     <maxIndex>${log.maxHistory}</maxIndex> 
    </rollingPolicy> 
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> 
     <maxFileSize>${log.default.maxFileSize}</maxFileSize> 
    </triggeringPolicy> 
    <encoder> 
     <pattern>%replace(${log.pattern}){'"pin":"\d+"','"pin":"XXXX"'}%n</pattern> 
    </encoder> 
</appender> 

<appender name="ASYNC-INFO" class="ch.qos.logback.classic.AsyncAppender"> 
    <discardingThreshold>${async.discardingThreshold}</discardingThreshold> 
    <queueSize>${async.queueSize}</queueSize> 
    <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> 
     <OnMismatch>DENY</OnMismatch> 
     <OnMatch>NEUTRAL</OnMatch> 
    </filter> 
    <appender-ref ref="INFO"/> 
</appender> 

<appender name="ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
    <file>${log.dir}/error.log</file> 
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> 
     <fileNamePattern>${log.dir}/error.%i.log.gz</fileNamePattern> 
     <maxIndex>${log.maxHistory}</maxIndex> 
    </rollingPolicy> 
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> 
     <maxFileSize>${log.error.maxFileSize}</maxFileSize> 
    </triggeringPolicy> 
    <encoder> 
     <pattern>%replace(${errorLog.pattern}){'"pin":"\d+"','"pin":"XXXX"'}%n</pattern> 
    </encoder> 
</appender> 

<appender name="ASYNC-ERROR" class="ch.qos.logback.classic.AsyncAppender"> 
    <discardingThreshold>${async.discardingThreshold}</discardingThreshold> 
    <queueSize>${async.queueSize}</queueSize> 
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> 
     <level>ERROR</level> 
    </filter> 

    <appender-ref ref="ERROR"/> 
</appender> 


<root level="INFO"> 
    <appender-ref ref="ASYNC-ERROR"/> 
    <appender-ref ref="ASYNC-INFO"/> 
</root> 

Answer 1

В нашем logback.xml мы указали,

<property name="async.discardingThreshold" value="0"/> 

Теперь быстрый взгляд на исходный код предполагает, что, возможно, может происходить что вызывая задержку во время поворота

@Override 
    protected void append(E eventObject) { 
    if (isQueueBelowDiscardingThreshold() && isDiscardable(eventObject)) { 
     return; 
    } 
    preprocess(eventObject); 
    put(eventObject); 
    } 
    private boolean isQueueBelowDiscardingThreshold() { 
    return (blockingQueue.remainingCapacity() < discardingThreshold); 
    } 

blockingQueue.remainingCapacity() < disardingThreshold, это условие никогда не будет оцениваться как true, если порог отбрасывания равен 0, что означает, что поток async-appender попытается нажать на уже заполненную очередь блокировки, следовательно, будет садиться и подождите, пока приложение также не будет ждать. Установка этого значения на что-либо выше 0, не вызывает таймаутов, однако некоторые события могут потеряться. Другим вариантом сохранения всех событий без отбрасывания было бы увеличить размер очереди столько, сколько в момент поворота файла не превышает размер элемента очереди в очереди. В этом случае поток async-appender не будет ждать очереди блокировки.

Так что мой вывод Logback AsyncAppender является НЕ так Асинхронный, если входящее сообщение скорость превышает скорость потребления очереди и скорость отбрасывания 0.