[
https://issues.apache.org/jira/browse/LOG4J2-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008129#comment-17008129
]
Ralph Goers commented on LOG4J2-2738:
-------------------------------------
[~mattsicker] No. The problem here is the following sequence:
# An application logs something.
# The log event is routed to an appender.
# That appender calls some library (Flume, Cassandra, Kafka, Hibernate are all
likely to do this).
# The library logs an event that is routed to the same appender.
# The appender calls the library to log the new event.
You now have infinite recursion. Log4j currently prevents that by ignoring
logging calls that flow to an appender that is already processing a logging
call. [~armbrust] is advocating that doing that is broken.
However, Dan's argument above is a little different as he is discussing
differences between DefaultLogEventFactory and ResusableLogEventFactory. Those
are only used to create a LogEvent from the individual parameters that were
passed in and really should have nothing to do with the recursive problem. But
I haven't had a chance to look at the demo he attached yet so I can't yet
comment on that.
> 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)
