[
https://issues.apache.org/jira/browse/LOG4J2-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-1649.
---------------------------------
Resolution: Fixed
Assignee: Ralph Goers
Fix Version/s: 2.8
I took a look at the patches. The change to RollingFileManager is similar to
what I had to do to get LOG4J2-1653 working. I took a different approach with
shutting down the ConfigurationScheduler that I believe will accomplish what is
needed. Without a test though I can't confirm it. Please verify and close if it
solves your problem, otherwise reopen and provide a test.
> 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
> Assignee: Ralph Goers
> Priority: Critical
> Fix For: 2.8
>
> Attachments: ConfigurationScheduler.patch, RollingFileManager.patch
>
>
> 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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
