Georg Friedrich created LOG4J2-1649:
---------------------------------------
Summary: 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 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
