[
https://issues.apache.org/jira/browse/LOG4J2-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008158#comment-17008158
]
Dan Armbrust commented on LOG4J2-2738:
--------------------------------------
Hi Ralph,
Want to tweak the sequence a little bit, because I think that this distinction
is important, to make it clear this isn't a case of an appender logging to
itself.
# An application logs something, *and passes a function as a parameter.*
# The log event is routed to an appender.
# That appender -calls some library (Flume, Cassandra, Kafka, Hibernate are
all likely to do this).- *calls the function to get the string value from the
function.*
# The -library- *function execution* logs an event that is routed to the same
appender.
# The appender -calls the library to log the new event.- *logs the new event.*
# *The appender logs the initial event, with the string computed by the
function.*
This sequence should NOT be determined to be an infinite recursion.
The reason that log4j works correctly in the above scenario for the
ReusableLogEventFactory case is that that factory executes the functions
*before* it starts tracking for recursion.
It is broken when it uses the DefaultLogEventFactory because that factory
*delays the function execution* until the last possible moment, after the
recursion tracking has already begun, which then mistakenly thinks its in an
infinite loop, when it is not.
> 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)
