logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Georg Friedrich (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-1649) CronTriggeringPolicy breaks awefully when using "reconfigure" of LoggerContext
Date Mon, 24 Oct 2016 13:51:58 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Georg Friedrich updated LOG4J2-1649:
------------------------------------
    Description: 
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 properly 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

  was:
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 results sets 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 properly 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


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


Mime
View raw message