[
https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258272#comment-16258272
]
Remko Popma commented on LOG4J2-2106:
-------------------------------------
[[email protected]] Looking back at your earlier comment
{quote}
Both rollover and checkRollover synchronize on the FileManager. So all calls to
checkRollover are synchronized and will be blocked by rollover. rollover calls
rollover(strategy). It waits for any async tasks to be completed before it will
execute (to prevent trying to compress the same file). This will cause a second
call to rollover to block until all async threads are complete, which will
cause threads to block waiting to log.
{quote}
So, when a rollover is in progress, we block the second call to {{rollover}} to
prevent two threads from trying to compress the same thing twice. How about,
instead of blocking in {{rollover}} we return immediately when we detect that a
rollover is already in progress? (The rollover request is essentially already
being honored by another thread. Seems pointless to wait and then perform
another rollover immediately after the first one...)
This could be done with a {{volatile boolean isRolloverInProgress}} flag that
is read before trying to acquire the lock (double checked locking pattern).
This should dramatically improve throughput without deep surgery of the code (I
hope).
> May blocked when two compress action
> ------------------------------------
>
> Key: LOG4J2-2106
> URL: https://issues.apache.org/jira/browse/LOG4J2-2106
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.9.1
> Reporter: skopt
>
> My log file is very large, so I set the config about compression. The
> policies is as follows:
> <Policies>
> <OnStartupTriggeringPolicy/>
> <TimeBasedTriggeringPolicy/>
> </Policies>
> When restart the service on the hour, this will trigger the two
> policies. And I find that the log can not be written for a while.
> I think, there would be two compress actions. In the file
> RollingFileManager(package org.apache.logging.log4j.core.appender.rolling),
> the actions will submit to asyncExecutor which will create a new thread for
> every work. That mean the log file will be compressed by the two actions. Is
> this the cause?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
