[
https://issues.apache.org/jira/browse/LOG4J2-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007081#comment-17007081
]
Carter Kozak commented on LOG4J2-2738:
--------------------------------------
I agree with [~rpopma] that we should provide a more insightful message in this
case, but I don't think we should allow nesting access to an appender control
because it would require every appender implementation to handle nested calls.
Consider an appender which receives an event (e.g. log.info("a {} b",
parameter)), and writes bytes to a file, but prior to completing the write,
toString is called on parameter which logs again (e.g. log.info("c")). This
would result in the following:
{noformat}
<pattern prefix: time, level> a <pattern prefix: time, level> c
parameterValue b{noformat}
Where we would expect the following lines (in either order I suppose):
{noformat}
<pattern prefix: time, level> a parameterValue b
<pattern prefix: time, level> c{noformat}
Perhaps we should reduce the severity of the status-logger logging in this case
from ERROR to WARN or even INFO in addition to improving the diagnostic message?
> 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)
