logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (LOG4J2-1368) Status logger drops/ignores exception
Date Fri, 15 Apr 2016 15:53:25 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Remko Popma closed LOG4J2-1368.

> Status logger drops/ignores exception
> -------------------------------------
>                 Key: LOG4J2-1368
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1368
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: API
>    Affects Versions: 2.5
>            Reporter: Remko Popma
>            Assignee: Remko Popma
>             Fix For: 2.6
> Internal log4j logging like below will just log the message but will not report the specified
> {code}
> try {
>     someProcess();
> } catch (Exception exception) {
>     StatusLogger.getLogger().warn("error occurred during {}", "some process", exception);
> }
> {code}
> This is caused by a bug in ParameterizedNoReferenceMessageFactory (the factory used by
> {code}
> final String formatted = new ParameterizedMessage(message, params).getFormattedMessage();
> return new SimpleMessage(formatted); // exception is dropped
> {code}
> This factory was introduced to resolve memory leaks that appeared in web containers because
StatusLogger keeps a ring buffer of previously logged messages and ParameterizedMessage keeps
a reference to its parameter objects (LOG4J2-1176).
> AbstractLogger depends on the Message to get the Throwable when logging a message with
parameters, so SimpleMessage is not good enough. I'm thinking to introduce a new class {{StatusMessage}}
(perhaps as an inner class of ParameterizedNoReferenceMessageFactory in order to keep the
API surface small). StatusMessage would have the formatted string and the Throwable (which
may be null). That should solve this issue.
> If the Throwable is a custom Log4j class like AppenderLoggingException then keeping a
reference to it may re-introduce memory leaks again though, but I guess that is a fight for
another day...

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message