[
https://issues.apache.org/jira/browse/LOG4J2-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496229#comment-15496229
]
Remko Popma commented on LOG4J2-1583:
-------------------------------------
I see the problem. Basically in the current code the same
ReusableParameterizedMessage is being used to service both the outer logger
call and the logging call in the parameter's toString() method.
The correct behaviour is obviously to have separate Message instances for the
separate logger calls. I will modify the ReusableMessageFactory to return new
messages as long as the reusable message instance is still in use. So the
reusable messages will only be reused when it is safe to do so.
> Nested logging call disrupts output of outer logging call
> ---------------------------------------------------------
>
> Key: LOG4J2-1583
> URL: https://issues.apache.org/jira/browse/LOG4J2-1583
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.6, 2.6.1, 2.6.2
> Environment: JVM 1.8.0_102, MacOS 10.11.6
> Reporter: Larry West
> Attachments: LOG4J-1583.tbz2, Log4j2ProblemDemo.java, log4j2.xml,
> pom.xml
>
>
> If a call to logger.info() invokes the toString() method on one of its
> parameters, and that toString() method invokes another method which has
> another, nested logging call, then the output of the outer call is mangled.
> This can be quite confusing as the nested logging may be conditional, or at
> DEBUG level, etc.
> Problem _appears_ to be related to ReusableParameterizedMessage.swapMessage()
> and the values in indices[]. (It looks inherently non-reentrant.)
--
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
