You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Georg Friedrich (JIRA)" <ji...@apache.org> on 2016/10/28 09:35:58 UTC

[jira] [Commented] (LOG4J2-1649) CronTriggeringPolicy breaks awefully when using "reconfigure" of LoggerContext

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

Georg Friedrich commented on LOG4J2-1649:
-----------------------------------------

I had some additional time to work on this and created two patched to resolve those issues. Please find them attached.
Those patches base on Log4J2 2.7. Feel free to write some tests for it, as I had no time to do so.

> CronTriggeringPolicy breaks awefully when using "reconfigure" of LoggerContext
> ------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1649
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1649
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.7
>            Reporter: Georg Friedrich
>            Priority: Critical
>
> Hi,
> I've a major problem when using CronTriggeringPolicy in Spring Boot environments.
> I've tracked the problem down to Log4J2.
> The following is happening:
> * When the Spring context is created, getContext is called which results in creation on the Log4J context and the cron trigger is registered as normal
> * After that Spring starts a reinitialization of the LoggerSystem by calling "reconfigure" of the LoggerContext of Log4J.
> * This results in very weird behvaiour of Log4J:
> ** Log4J finds the already created RollingFileManager in the "MAP" field in the AbstractManager class.
> ** As it was already available it calls the "updateData" which in result registers the trigger again.
> ** After that the "initialize" method is called on the RollingFileManager, which again registers the trigger. (The cron trigger is now scheduled 3 times! First time by the normal getContext initialization and two times more by the reconfiguration)
> The good thing is: As the old configuration gets destroyed, the old scheduler is being shutdown too, but the last schedule of the first cron trigger is called nevertheless.
> So basically you get 3 cron trigger calls, where 2 of them are rescheduled.
> How it should be fixed (from my point of view):
> * Kill old CronTriggers from scheduling when the context gets reconfigured
> * Do not call initialize for the triggering policy when the RollingFileManager is updated as this is done afterwards nevertheless



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org