[
https://issues.apache.org/jira/browse/LOG4J2-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15793606#comment-15793606
]
Georg Friedrich commented on LOG4J2-1649:
-----------------------------------------
You should be aware that this would also get called when the whole Log4J2
context is reconfigured (as stated in the ticket description).
Therefore it would possibly interrupt tasks that are currently running while
just doing a normal operation on the Log4J context (not a shutdown from the
applications point of view).
> 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
