[
https://issues.apache.org/jira/browse/LOG4J2-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008235#comment-17008235
]
Ralph Goers commented on LOG4J2-2738:
-------------------------------------
As I recall when async is enabled the Message has to be formatted before it is
passed to the thread, otherwise it could suffer from race conditions. So we
already incur this overhead for that. However, we have never wanted to eagerly
format Messages until they are actually needed by Appenders for the synchronous
case so as not to needlessly incur that overhead. I would not want to see that
behavior change.
Your changes don't really change anything. Log4j can't know what is doing the
logging - be it a function or a library. The fact is the Appender is being
called a second time recursively. Log4j doesn't know why or how. So the
distinction between calling a function and calling a library doesn't really
matter. They are both doing logging and as far as Log4j is concerned are likely
to do it again and again.
> Message "ERROR Recursive call to appender" needs more diagnostic information.
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-2738
> URL: https://issues.apache.org/jira/browse/LOG4J2-2738
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.12.1
> Reporter: Dan Armbrust
> Assignee: Ralph Goers
> Priority: Minor
> Attachments: Log4JRecurseTest.java, log4j2.xml
>
>
> The class AppenderControl has logic that is intended to detect recursive
> calls to an appender.
>
> {code:java}
> // code placeholder
> @PerformanceSensitive
> private boolean isRecursiveCall() {
> if (recursive.get() != null) {
> appenderErrorHandlerMessage("Recursive call to appender ");
> return true;
> }
> return false;
> }
> {code}
> However, the logic behind this is flawed, leading to erroneous ERROR messages
> being printed on the console.
> In my use case, I have a log message being written, utilizing the
> ParameterizedMessage APIs. When log4j formats my message, it calls the
> toString method on the object being passed in. If that toString() call
> results in another log message being written, log4j logs this error, which I
> believe to be erroneous. Its not recursive... its just another log message
> that happens to be triggered by the construction of the first log message.
> This wouldn't lead to a recursive loop.
> This should probably be implemented with a depth counter, and only error if
> it really does look recursive (deeper than 10 calls, or some such value).
> Also, the error logged should REALLY include a stack trace, so this isn't
> such a PITA to track down if someone really does have a recursive logging
> call.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
