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

["Georg Friedrich (JIRA)" <ji...@apache.org>]

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

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

Hi Ralph,

well, there was a reason for doing it the way it was done in the patches.
First I didn't want to interrupt the running threads as I was not sure whether it would be problematic for the eventually currently running rollover. If you are sure it is fine, I'm fine too.
Second, be aware that shutdownNow() doesn't return the currently running task which means that the list might be empty but the scheduler is still executing stuff. Your if-statement wouldn't work in this case.

This is why I decided to remove all "not yet executing"-tasks from the scheduler, but let the scheduler exit normally without interrupting currently executing tasks.

> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org