You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@logging.apache.org by "Paul Togher (JIRA)" <ji...@apache.org> on 2019/02/21 22:17:00 UTC

[jira] [Comment Edited] (LOG4J2-2552) Allow access to the backlog state of the disruptor to improve programatic reconfiguration of async appenders.

    [ https://issues.apache.org/jira/browse/LOG4J2-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16774545#comment-16774545 ] 

Paul Togher edited comment on LOG4J2-2552 at 2/21/19 10:16 PM:
---------------------------------------------------------------

Is there a way to link this to my pull request? I have added the Jira number to the title of PR. https://github.com/apache/logging-log4j2/pull/257


was (Author: ptogher):
Is there a way to link this to my pull request? I have added the Jira number to the title of PR.

> Allow access to the backlog state of the disruptor to improve programatic reconfiguration of async appenders.
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-2552
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2552
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Paul Togher
>            Priority: Trivial
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> This change is to help support programmatically switching async appenders. In cases where it is important that logged messages go to the appender that was configured at the time of writing the log event, the flushing the appender buffer to disk is not sufficient, as the log events may still be in the disruptor. This change provides access to test if the disruptor has items in its backlog. This becomes useful in an application that is controlling its logging config and logging events to ensure that no new logging events are generated between removing one appender and adding another, so that it can also ensure the change does not happen until all pending log events are processed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)