[
https://issues.apache.org/jira/browse/LOG4J2-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563964#comment-14563964
]
Gary Gregory edited comment on LOG4J2-927 at 5/29/15 12:23 AM:
---------------------------------------------------------------
Note that:
Version 2.3 fixed:
# [LOG4J2-985] AbstractFilter should not implement equals() and hashCode().
Version 2.2 fixed:
# [LOG4J2-881] AbstractLifecycle should not implement equals() and hashCode().
and there are a couple of other duplicate issues in 2.2 for this.
was (Author: garydgregory):
Note that version 2.2 fixed [LOG4J2-881] AbstractLifecycle should not implement
equals() and hashCode().
> Race condition between a LoggerContext stop() and async loggers
> ---------------------------------------------------------------
>
> Key: LOG4J2-927
> URL: https://issues.apache.org/jira/browse/LOG4J2-927
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.1
> Reporter: Mariano Gonzalez
>
> I have an application in which I'm using all async loggers. When I stop the
> LoggerContext, there're still some events waiting in disruptor's buffer and
> when it tries to execute them the context is already closed and thus those
> events are lost. In the case of a RollingFileAppender, I get an IOException
> because the outputStream has already been closed.
> As a debugging technique, I did an Appedder decorator that looks like this:
> {code:java}
> final class StopConditionSafeAppenderWrapper extends BaseAppenderWrapper
> {
> private final LoggerContext loggerContext;
> StopConditionSafeAppenderWrapper(Appender delegate, LoggerContext
> loggerContext)
> {
> super(delegate);
> this.loggerContext = loggerContext;
> }
> @Override
> public void append(LogEvent event)
> {
> if (!loggerContext.isStarted()) {
> return;
> }
> super.append(event);
> }
> }
> {code}
> With the help of a debugger, I could verify that when the append method was
> invoked the loggerContext was started but then by the time the exception
> occurred it was closed.
> It checked the code at LoggerContext#stop() and saw that there's code to
> prevent disruptor from taking new events once a stop() has been invoked, but
> there's no code to wait for the ring buffer to be fully consumed before
> actually stopping.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
