Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.13.3
    • None
    • API
    • None

    Description

      We're encountering an issue similar to LOG4J2-2792 and LOG4J2-2880 but it isn't because of the use of Location, but because of the use of dynamically created loggers that we then refer to via org.slf4j.LoggerFactory.getLogger(method.getDeclaringClass()). This attempts to get the caller class and ends up walking the stack as in the stack trace example below. This is known to be rather problematic (from the performance perspective) and even becomes worse with the time (until the JVM restart, or full GC) - https://bugs.openjdk.java.net/browse/JDK-8222942 for example.

      However instead of doing it this rather expensive way, it may be possible to use an improved approach similar to what jboss-logging library developers used when working on the following issues:
      https://bugzilla.redhat.com/show_bug.cgi?id=1813436
      https://issues.redhat.com/browse/LOGMGR-263
      The related commit: https://github.com/jboss-logging/jboss-logmanager/commit/fc1fc3b509df9797ff06a423878a5b113f6281f8
      Can you check whether something useful may be brought in from that?

      at java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(java.base@11.0.8/Native Method)
      at java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(java.base@11.0.8/StackStreamFactory.java:386)
      at java.lang.StackStreamFactory$AbstractStackWalker.getNextBatch(java.base@11.0.8/StackStreamFactory.java:322)
      at java.lang.StackStreamFactory$AbstractStackWalker.peekFrame(java.base@11.0.8/StackStreamFactory.java:263)
      at java.lang.StackStreamFactory$AbstractStackWalker.hasNext(java.base@11.0.8/StackStreamFactory.java:351)
      at java.lang.StackStreamFactory$StackFrameTraverser.tryAdvance(java.base@11.0.8/StackStreamFactory.java:593)
      at java.util.stream.ReferencePipeline.forEachWithCancel(java.base@11.0.8/ReferencePipeline.java:127)
      at java.util.stream.AbstractPipeline.copyIntoWithCancel(java.base@11.0.8/AbstractPipeline.java:502)
      at java.util.stream.AbstractPipeline.copyInto(java.base@11.0.8/AbstractPipeline.java:488)
      at java.util.stream.AbstractPipeline.wrapAndCopyInto(java.base@11.0.8/AbstractPipeline.java:474)
      at java.util.stream.FindOps$FindOp.evaluateSequential(java.base@11.0.8/FindOps.java:150)
      at java.util.stream.AbstractPipeline.evaluate(java.base@11.0.8/AbstractPipeline.java:234)
      at java.util.stream.ReferencePipeline.findFirst(java.base@11.0.8/ReferencePipeline.java:543)
      at org.apache.logging.log4j.util.StackLocator.lambda$getCallerClass$6(StackLocator.java:58)
      at org.apache.logging.log4j.util.StackLocator$$Lambda$1226/0x00000008414fec40.apply(Unknown Source)
      at java.lang.StackStreamFactory$StackFrameTraverser.consumeFrames(java.base@11.0.8/StackStreamFactory.java:534)
      at java.lang.StackStreamFactory$AbstractStackWalker.doStackWalk(java.base@11.0.8/StackStreamFactory.java:306)
      at java.lang.StackStreamFactory$AbstractStackWalker.callStackWalk(java.base@11.0.8/Native Method)
      at java.lang.StackStreamFactory$AbstractStackWalker.beginStackWalk(java.base@11.0.8/StackStreamFactory.java:370)
      at java.lang.StackStreamFactory$AbstractStackWalker.walk(java.base@11.0.8/StackStreamFactory.java:243)
      at java.lang.StackWalker.walk(java.base@11.0.8/StackWalker.java:498)
      at org.apache.logging.log4j.util.StackLocator.getCallerClass(StackLocator.java:57)
      at org.apache.logging.log4j.util.StackLocatorUtil.getCallerClass(StackLocatorUtil.java:67)
      at org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:45)
      at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:48)
      at org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:30)
      at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
      at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
      at LoggerAspect.isLogLevelEnabled(LoggerAspect.java:91)
      ...

      Attachments

        Issue Links

        Activity

          rgoers Ralph Goers added a comment -

          I guess I should be flattered. I wasn't aware that JBoss had copied our approach to have a LoggerContext be associated with ClassLoaders.

          I will certainly take a look at the JBoss code to see how it is different. I am very pleasantly surprised to see that the linked class is licensed with the Apache License so we could just copy the code if needed.

          rgoers Ralph Goers added a comment - I guess I should be flattered. I wasn't aware that JBoss had copied our approach to have a LoggerContext be associated with ClassLoaders. I will certainly take a look at the JBoss code to see how it is different. I am very pleasantly surprised to see that the linked class is licensed with the Apache License so we could just copy the code if needed.
          rgoers Ralph Goers added a comment - - edited

          Looking at the JBoss implementation I see that they are keeping track of the LoggerContext in a Map with the ClassLoader as the key. Maybe JBoss can get away with that but Log4j cannot. Instead, Log4j stores the LoggerContext in a Map where the key is the identity hashcode of the ClassLoader. This should have the same benefit with minimal extra overhead and won't run the risk of causing ClassLoader leakage. 

          The comments for ClassLoaderContextSelector are "A log context selector which chooses a log context based on the caller's classloader.", but that doesn't seem to be what it does at all.

          The algorithm JBoss seems to be using is:

          1. Call the JDK specific LogContextFinder passing in the Map of previously located LogContexts and the LogContextFinder function (which just walks the ClassLoader parent chain looking for the first LogContext it finds in the ContextMap).
          2. Walks the StackFrames until it finds one whose class is associated with a ClassLoader that can be found in the Map.
          3. If it doesn't find one it returns the default LogContext.

          What really has me confused is I don't see any code that adds LogContext's to the contextMap other than the registerLogContext method in ClassLoaderContextSelector that IntelliJ says is never used. So it appears that all this code ever does is return the default LogContext. Without some algorithm to tell it to add a LogContext to the Map I don't see how the JBoss code can be doing what it should be doing. I also don't see any tests in the jboss-logging or jboss-logmanager projects to test this.

          Am I misreading the code somehow?

          I should contrast the algorithm that JBoss uses with the one Log4j uses:

          1. If the currentContext parameter is true then return the LoggerContext associated with the ContextAnchor ThreadLocal. If one is not present the default LoggerContext is returned.
          2. If the ClassLoader was specified locate the LoggerContext associated with it, otherwise locate the caller's class (using StackLocatorUtil), get its ClassLoader and locate the LoggerContext associated with it.
          3. To locate the LoggerContext check if the ClassLoader's identity is present as a key in the contextMap. If it is return the LoggerContext. If not recursively check its parents.
          4. Since no LoggerContext could be located, create a new one and register it using the ClassLoader's identity as the key and return the created LoggerContext.

          After looking at the stack trace you provided I see that it isn't even in Log4j's ClassLoaderContextSelector but the SLF4J adapter's getContext method. It is trying to resolve the calling class to get its ClassLoader to pass to the above algorithm. This probably shouldn't be handled this way because it you have chosen to use a ContextSelector other than ClassLoaderContextSelect than determining the caller's ClassLoader may be a waste of time. It should probably just pass the FQCN.

          I should also note that I have changed the algorithm the Java 9 version of StackLocator is using. After doing further testing for LOG4J2-2880 I discovered that the algorithm Log4j 2 originally used was better than what is in 2.13.3 so that will be of some help in 2.14.0.  That said, I suspect if I could directly access the array of StackFrames using a for loop would be much faster than using Streams.

          rgoers Ralph Goers added a comment - - edited Looking at the JBoss implementation I see that they are keeping track of the LoggerContext in a Map with the ClassLoader as the key. Maybe JBoss can get away with that but Log4j cannot. Instead, Log4j stores the LoggerContext in a Map where the key is the identity hashcode of the ClassLoader. This should have the same benefit with minimal extra overhead and won't run the risk of causing ClassLoader leakage.  The comments for ClassLoaderContextSelector are "A log context selector which chooses a log context based on the caller's classloader.", but that doesn't seem to be what it does at all. The algorithm JBoss seems to be using is: Call the JDK specific LogContextFinder passing in the Map of previously located LogContexts and the LogContextFinder function (which just walks the ClassLoader parent chain looking for the first LogContext it finds in the ContextMap). Walks the StackFrames until it finds one whose class is associated with a ClassLoader that can be found in the Map. If it doesn't find one it returns the default LogContext. What really has me confused is I don't see any code that adds LogContext's to the contextMap other than the registerLogContext method in ClassLoaderContextSelector that IntelliJ says is never used. So it appears that all this code ever does is return the default LogContext. Without some algorithm to tell it to add a LogContext to the Map I don't see how the JBoss code can be doing what it should be doing. I also don't see any tests in the jboss-logging or jboss-logmanager projects to test this. Am I misreading the code somehow? I should contrast the algorithm that JBoss uses with the one Log4j uses: If the currentContext parameter is true then return the LoggerContext associated with the ContextAnchor ThreadLocal. If one is not present the default LoggerContext is returned. If the ClassLoader was specified locate the LoggerContext associated with it, otherwise locate the caller's class (using StackLocatorUtil), get its ClassLoader and locate the LoggerContext associated with it. To locate the LoggerContext check if the ClassLoader's identity is present as a key in the contextMap. If it is return the LoggerContext. If not recursively check its parents. Since no LoggerContext could be located, create a new one and register it using the ClassLoader's identity as the key and return the created LoggerContext. After looking at the stack trace you provided I see that it isn't even in Log4j's ClassLoaderContextSelector but the SLF4J adapter's getContext method. It is trying to resolve the calling class to get its ClassLoader to pass to the above algorithm. This probably shouldn't be handled this way because it you have chosen to use a ContextSelector other than ClassLoaderContextSelect than determining the caller's ClassLoader may be a waste of time. It should probably just pass the FQCN. I should also note that I have changed the algorithm the Java 9 version of StackLocator is using. After doing further testing for LOG4J2-2880 I discovered that the algorithm Log4j 2 originally used was better than what is in 2.13.3 so that will be of some help in 2.14.0.  That said, I suspect if I could directly access the array of StackFrames using a for loop would be much faster than using Streams.
          hostalp Peter H added a comment -

          ... SLF4J adapter's getContext method. It is trying to resolve the calling class to get its ClassLoader to pass to the above algorithm. This probably shouldn't be handled this way because it you have chosen to use a ContextSelector other than ClassLoaderContextSelect than determining the caller's ClassLoader may be a waste of time. It should probably just pass the FQCN.

          If that's the case it may be possible to correct the SLF4J adapter's code (Log4jLoggerFactory?) to handle such cases more efficiently right there. Correct?

          hostalp Peter H added a comment - ... SLF4J adapter's getContext method. It is trying to resolve the calling class to get its ClassLoader to pass to the above algorithm. This probably shouldn't be handled this way because it you have chosen to use a ContextSelector other than ClassLoaderContextSelect than determining the caller's ClassLoader may be a waste of time. It should probably just pass the FQCN. If that's the case it may be possible to correct the SLF4J adapter's code (Log4jLoggerFactory?) to handle such cases more efficiently right there. Correct?
          rgoers Ralph Goers added a comment -

          Yes, but it won't make much difference unless you configure your app to use a different ContextSelector.

          rgoers Ralph Goers added a comment - Yes, but it won't make much difference unless you configure your app to use a different ContextSelector.
          rgoers Ralph Goers added a comment -

          We should a) investigate whether we can a) use StackWalker.getCallerClass() directly in LoggerFactory.getLogger() as that method is supposed to be much faster than walking the stack and b) check to see what the overhead of that is. We may also want to add a method to LogManager to determine if the ContextSelector requires the ClassLoader, in which case we could skip the call.

          rgoers Ralph Goers added a comment - We should a) investigate whether we can a) use StackWalker.getCallerClass() directly in LoggerFactory.getLogger() as that method is supposed to be much faster than walking the stack and b) check to see what the overhead of that is. We may also want to add a method to LogManager to determine if the ContextSelector requires the ClassLoader, in which case we could skip the call.
          rgoers Ralph Goers added a comment -

          Adding support for SLF4J-2.0.0 is likely going to impact how this problem gets solved so LOG4J2-2975 should be handled first.

          rgoers Ralph Goers added a comment - Adding support for SLF4J-2.0.0 is likely going to impact how this problem gets solved so LOG4J2-2975 should be handled first.
          ckozak Carter Kozak added a comment -

          I'm looking into adding a method to the context-selector which tells us whether or not the classloader is required to determine the context as you proposed on the mailing list, Ralph Goershttps://lists.apache.org/thread.html/r6ca27440676839d645b2f33baed207c3e5ac86f18221f7a2577fd777%40%3Clog4j-user.logging.apache.org%3E

          ckozak Carter Kozak added a comment - I'm looking into adding a method to the context-selector which tells us whether or not the classloader is required to determine the context as you proposed on the mailing list, Ralph Goers :  https://lists.apache.org/thread.html/r6ca27440676839d645b2f33baed207c3e5ac86f18221f7a2577fd777%40%3Clog4j-user.logging.apache.org%3E
          rgoers Ralph Goers added a comment -

          Sure. If you wouldn't mind could you do it as a PR so I can easily review it?

          rgoers Ralph Goers added a comment - Sure. If you wouldn't mind could you do it as a PR so I can easily review it?
          ckozak Carter Kozak added a comment -

          Of course, I've opened one here: https://github.com/apache/logging-log4j2/pull/475

          ckozak Carter Kozak added a comment - Of course, I've opened one here:  https://github.com/apache/logging-log4j2/pull/475

          Commit 79c187a3ef2dbc63dfc831d74d6854f11ef3f8f7 in logging-log4j2's branch refs/heads/master from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=79c187a ]

          LOG4J2-2940: Context selectors are aware of ClassLoader dependency

          This allows LoggerContext lookups to avoid searching for the calling
          class to discover a classloader when the ContextSelector implementation
          is declared to be agnostic to the class loader.

          Custom LoggerContextFactory and ContextSelector implementations
          should be updated to override the new `isClassLoaderDependent` method.

          jira-bot ASF subversion and git services added a comment - Commit 79c187a3ef2dbc63dfc831d74d6854f11ef3f8f7 in logging-log4j2's branch refs/heads/master from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=79c187a ] LOG4J2-2940 : Context selectors are aware of ClassLoader dependency This allows LoggerContext lookups to avoid searching for the calling class to discover a classloader when the ContextSelector implementation is declared to be agnostic to the class loader. Custom LoggerContextFactory and ContextSelector implementations should be updated to override the new `isClassLoaderDependent` method.

          Commit c217cd5b06a63e1948fdea8be8e79e6a1deaf859 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c217cd5 ]

          LOG4J2-2940: Context selectors are aware of ClassLoader dependency

          This allows LoggerContext lookups to avoid searching for the calling
          class to discover a classloader when the ContextSelector implementation
          is declared to be agnostic to the class loader.

          Custom LoggerContextFactory and ContextSelector implementations
          should be updated to override the new `isClassLoaderDependent` method.

          jira-bot ASF subversion and git services added a comment - Commit c217cd5b06a63e1948fdea8be8e79e6a1deaf859 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c217cd5 ] LOG4J2-2940 : Context selectors are aware of ClassLoader dependency This allows LoggerContext lookups to avoid searching for the calling class to discover a classloader when the ContextSelector implementation is declared to be agnostic to the class loader. Custom LoggerContextFactory and ContextSelector implementations should be updated to override the new `isClassLoaderDependent` method.

          Commit cefa59383c560af7ba03300601a61d82480ffd67 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=cefa593 ]

          LOG4J2-2940: Reduce StackWalker interactions accessing an slf4j logger instance

          Previously we walked the stack twice, once to find the
          `org.slf4j.LoggerFactory` interaction, and a second time to
          discover the application code which called it. Now we use a new
          API to skip a frame at the end to find the final result in a single
          interaction.

          jira-bot ASF subversion and git services added a comment - Commit cefa59383c560af7ba03300601a61d82480ffd67 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=cefa593 ] LOG4J2-2940 : Reduce StackWalker interactions accessing an slf4j logger instance Previously we walked the stack twice, once to find the `org.slf4j.LoggerFactory` interaction, and a second time to discover the application code which called it. Now we use a new API to skip a frame at the end to find the final result in a single interaction.

          Commit d819f0a38293740137e40fbe05c03c2fb24e7fc3 in logging-log4j2's branch refs/heads/master from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=d819f0a ]

          LOG4J2-2940: Reduce StackWalker interactions accessing an slf4j logger instance

          Previously we walked the stack twice, once to find the
          `org.slf4j.LoggerFactory` interaction, and a second time to
          discover the application code which called it. Now we use a new
          API to skip a frame at the end to find the final result in a single
          interaction.

          jira-bot ASF subversion and git services added a comment - Commit d819f0a38293740137e40fbe05c03c2fb24e7fc3 in logging-log4j2's branch refs/heads/master from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=d819f0a ] LOG4J2-2940 : Reduce StackWalker interactions accessing an slf4j logger instance Previously we walked the stack twice, once to find the `org.slf4j.LoggerFactory` interaction, and a second time to discover the application code which called it. Now we use a new API to skip a frame at the end to find the final result in a single interaction.

          Commit 12bd5bf77939f276cf4bfbcb867085bf0dfdd568 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=12bd5bf ]

          LOG4J2-2940: Implement BasicAsyncLoggerContextSelector

          The BasicAsyncLoggerContextSelector is equivalent to the
          AsyncLoggerContextSelector without ClassLoader introspection
          and associated overhead.

          jira-bot ASF subversion and git services added a comment - Commit 12bd5bf77939f276cf4bfbcb867085bf0dfdd568 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=12bd5bf ] LOG4J2-2940 : Implement BasicAsyncLoggerContextSelector The BasicAsyncLoggerContextSelector is equivalent to the AsyncLoggerContextSelector without ClassLoader introspection and associated overhead.

          Commit 702787e1d37f9becec1751b819013e687e588bb5 in logging-log4j2's branch refs/heads/master from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=702787e ]

          LOG4J2-2940: Implement BasicAsyncLoggerContextSelector

          The BasicAsyncLoggerContextSelector is equivalent to the
          AsyncLoggerContextSelector without ClassLoader introspection
          and associated overhead.

          jira-bot ASF subversion and git services added a comment - Commit 702787e1d37f9becec1751b819013e687e588bb5 in logging-log4j2's branch refs/heads/master from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=702787e ] LOG4J2-2940 : Implement BasicAsyncLoggerContextSelector The BasicAsyncLoggerContextSelector is equivalent to the AsyncLoggerContextSelector without ClassLoader introspection and associated overhead.

          Commit 459d7ad8c99bd1ebff5d4b341a447f5593806c25 in logging-log4j2's branch refs/heads/master-java11 from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=459d7ad ]

          LOG4J2-2940: Context selectors are aware of ClassLoader dependency

          This allows LoggerContext lookups to avoid searching for the calling
          class to discover a classloader when the ContextSelector implementation
          is declared to be agnostic to the class loader.

          Custom LoggerContextFactory and ContextSelector implementations
          should be updated to override the new `isClassLoaderDependent` method.

          jira-bot ASF subversion and git services added a comment - Commit 459d7ad8c99bd1ebff5d4b341a447f5593806c25 in logging-log4j2's branch refs/heads/master-java11 from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=459d7ad ] LOG4J2-2940 : Context selectors are aware of ClassLoader dependency This allows LoggerContext lookups to avoid searching for the calling class to discover a classloader when the ContextSelector implementation is declared to be agnostic to the class loader. Custom LoggerContextFactory and ContextSelector implementations should be updated to override the new `isClassLoaderDependent` method.

          Commit 07b0fad4280736566bede9b7a89bd5f384926359 in logging-log4j2's branch refs/heads/master-java11 from Ralph Goers
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=07b0fad ]

          LOG4J2-2940: Reduce StackWalker interactions accessing an slf4j logger instance

          Previously we walked the stack twice, once to find the
          `org.slf4j.LoggerFactory` interaction, and a second time to
          discover the application code which called it. Now we use a new
          API to skip a frame at the end to find the final result in a single
          interaction.

          jira-bot ASF subversion and git services added a comment - Commit 07b0fad4280736566bede9b7a89bd5f384926359 in logging-log4j2's branch refs/heads/master-java11 from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=07b0fad ] LOG4J2-2940 : Reduce StackWalker interactions accessing an slf4j logger instance Previously we walked the stack twice, once to find the `org.slf4j.LoggerFactory` interaction, and a second time to discover the application code which called it. Now we use a new API to skip a frame at the end to find the final result in a single interaction.

          Commit f42f81c5b4644cceca7cdadf472091efc0360983 in logging-log4j2's branch refs/heads/master-java11 from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f42f81c ]

          LOG4J2-2940: Implement BasicAsyncLoggerContextSelector

          The BasicAsyncLoggerContextSelector is equivalent to the
          AsyncLoggerContextSelector without ClassLoader introspection
          and associated overhead.

          jira-bot ASF subversion and git services added a comment - Commit f42f81c5b4644cceca7cdadf472091efc0360983 in logging-log4j2's branch refs/heads/master-java11 from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f42f81c ] LOG4J2-2940 : Implement BasicAsyncLoggerContextSelector The BasicAsyncLoggerContextSelector is equivalent to the AsyncLoggerContextSelector without ClassLoader introspection and associated overhead.

          Commit 459d7ad8c99bd1ebff5d4b341a447f5593806c25 in logging-log4j2's branch refs/heads/master from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=459d7ad ]

          LOG4J2-2940: Context selectors are aware of ClassLoader dependency

          This allows LoggerContext lookups to avoid searching for the calling
          class to discover a classloader when the ContextSelector implementation
          is declared to be agnostic to the class loader.

          Custom LoggerContextFactory and ContextSelector implementations
          should be updated to override the new `isClassLoaderDependent` method.

          jira-bot ASF subversion and git services added a comment - Commit 459d7ad8c99bd1ebff5d4b341a447f5593806c25 in logging-log4j2's branch refs/heads/master from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=459d7ad ] LOG4J2-2940 : Context selectors are aware of ClassLoader dependency This allows LoggerContext lookups to avoid searching for the calling class to discover a classloader when the ContextSelector implementation is declared to be agnostic to the class loader. Custom LoggerContextFactory and ContextSelector implementations should be updated to override the new `isClassLoaderDependent` method.

          Commit 07b0fad4280736566bede9b7a89bd5f384926359 in logging-log4j2's branch refs/heads/master from Ralph Goers
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=07b0fad ]

          LOG4J2-2940: Reduce StackWalker interactions accessing an slf4j logger instance

          Previously we walked the stack twice, once to find the
          `org.slf4j.LoggerFactory` interaction, and a second time to
          discover the application code which called it. Now we use a new
          API to skip a frame at the end to find the final result in a single
          interaction.

          jira-bot ASF subversion and git services added a comment - Commit 07b0fad4280736566bede9b7a89bd5f384926359 in logging-log4j2's branch refs/heads/master from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=07b0fad ] LOG4J2-2940 : Reduce StackWalker interactions accessing an slf4j logger instance Previously we walked the stack twice, once to find the `org.slf4j.LoggerFactory` interaction, and a second time to discover the application code which called it. Now we use a new API to skip a frame at the end to find the final result in a single interaction.

          Commit f42f81c5b4644cceca7cdadf472091efc0360983 in logging-log4j2's branch refs/heads/master from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f42f81c ]

          LOG4J2-2940: Implement BasicAsyncLoggerContextSelector

          The BasicAsyncLoggerContextSelector is equivalent to the
          AsyncLoggerContextSelector without ClassLoader introspection
          and associated overhead.

          jira-bot ASF subversion and git services added a comment - Commit f42f81c5b4644cceca7cdadf472091efc0360983 in logging-log4j2's branch refs/heads/master from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f42f81c ] LOG4J2-2940 : Implement BasicAsyncLoggerContextSelector The BasicAsyncLoggerContextSelector is equivalent to the AsyncLoggerContextSelector without ClassLoader introspection and associated overhead.

          Commit 07b0fad4280736566bede9b7a89bd5f384926359 in logging-log4j2's branch refs/heads/dependabot/maven/org.codehaus.mojo-build-helper-maven-plugin-3.2.0 from Ralph Goers
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=07b0fad ]

          LOG4J2-2940: Reduce StackWalker interactions accessing an slf4j logger instance

          Previously we walked the stack twice, once to find the
          `org.slf4j.LoggerFactory` interaction, and a second time to
          discover the application code which called it. Now we use a new
          API to skip a frame at the end to find the final result in a single
          interaction.

          jira-bot ASF subversion and git services added a comment - Commit 07b0fad4280736566bede9b7a89bd5f384926359 in logging-log4j2's branch refs/heads/dependabot/maven/org.codehaus.mojo-build-helper-maven-plugin-3.2.0 from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=07b0fad ] LOG4J2-2940 : Reduce StackWalker interactions accessing an slf4j logger instance Previously we walked the stack twice, once to find the `org.slf4j.LoggerFactory` interaction, and a second time to discover the application code which called it. Now we use a new API to skip a frame at the end to find the final result in a single interaction.

          Commit f42f81c5b4644cceca7cdadf472091efc0360983 in logging-log4j2's branch refs/heads/dependabot/maven/org.codehaus.mojo-build-helper-maven-plugin-3.2.0 from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f42f81c ]

          LOG4J2-2940: Implement BasicAsyncLoggerContextSelector

          The BasicAsyncLoggerContextSelector is equivalent to the
          AsyncLoggerContextSelector without ClassLoader introspection
          and associated overhead.

          jira-bot ASF subversion and git services added a comment - Commit f42f81c5b4644cceca7cdadf472091efc0360983 in logging-log4j2's branch refs/heads/dependabot/maven/org.codehaus.mojo-build-helper-maven-plugin-3.2.0 from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f42f81c ] LOG4J2-2940 : Implement BasicAsyncLoggerContextSelector The BasicAsyncLoggerContextSelector is equivalent to the AsyncLoggerContextSelector without ClassLoader introspection and associated overhead.
          rgoers Ralph Goers added a comment -

          Carter Kozak Isn't this now resolved?

          rgoers Ralph Goers added a comment - Carter Kozak  Isn't this now resolved?

          Commit c217cd5b06a63e1948fdea8be8e79e6a1deaf859 in logging-log4j2's branch refs/heads/LOG4J2-3004 from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c217cd5 ]

          LOG4J2-2940: Context selectors are aware of ClassLoader dependency

          This allows LoggerContext lookups to avoid searching for the calling
          class to discover a classloader when the ContextSelector implementation
          is declared to be agnostic to the class loader.

          Custom LoggerContextFactory and ContextSelector implementations
          should be updated to override the new `isClassLoaderDependent` method.

          jira-bot ASF subversion and git services added a comment - Commit c217cd5b06a63e1948fdea8be8e79e6a1deaf859 in logging-log4j2's branch refs/heads/ LOG4J2-3004 from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c217cd5 ] LOG4J2-2940 : Context selectors are aware of ClassLoader dependency This allows LoggerContext lookups to avoid searching for the calling class to discover a classloader when the ContextSelector implementation is declared to be agnostic to the class loader. Custom LoggerContextFactory and ContextSelector implementations should be updated to override the new `isClassLoaderDependent` method.

          Commit cefa59383c560af7ba03300601a61d82480ffd67 in logging-log4j2's branch refs/heads/LOG4J2-3004 from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=cefa593 ]

          LOG4J2-2940: Reduce StackWalker interactions accessing an slf4j logger instance

          Previously we walked the stack twice, once to find the
          `org.slf4j.LoggerFactory` interaction, and a second time to
          discover the application code which called it. Now we use a new
          API to skip a frame at the end to find the final result in a single
          interaction.

          jira-bot ASF subversion and git services added a comment - Commit cefa59383c560af7ba03300601a61d82480ffd67 in logging-log4j2's branch refs/heads/ LOG4J2-3004 from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=cefa593 ] LOG4J2-2940 : Reduce StackWalker interactions accessing an slf4j logger instance Previously we walked the stack twice, once to find the `org.slf4j.LoggerFactory` interaction, and a second time to discover the application code which called it. Now we use a new API to skip a frame at the end to find the final result in a single interaction.

          Commit 12bd5bf77939f276cf4bfbcb867085bf0dfdd568 in logging-log4j2's branch refs/heads/LOG4J2-3004 from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=12bd5bf ]

          LOG4J2-2940: Implement BasicAsyncLoggerContextSelector

          The BasicAsyncLoggerContextSelector is equivalent to the
          AsyncLoggerContextSelector without ClassLoader introspection
          and associated overhead.

          jira-bot ASF subversion and git services added a comment - Commit 12bd5bf77939f276cf4bfbcb867085bf0dfdd568 in logging-log4j2's branch refs/heads/ LOG4J2-3004 from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=12bd5bf ] LOG4J2-2940 : Implement BasicAsyncLoggerContextSelector The BasicAsyncLoggerContextSelector is equivalent to the AsyncLoggerContextSelector without ClassLoader introspection and associated overhead.
          ckozak Carter Kozak added a comment -

          > Isn't this now resolved?

          I think we can consider it resolved – I expect that we're still spending more cycles than java 8 when the ClassLoaderContextSelector (default) and AsyncLoggerContextSelector are used, but it's half as expensive as it was prior to my changes. BasicContextSelector and the new BasicAsyncLoggerContextSelector definitely solve the problem when they're used.

          ckozak Carter Kozak added a comment - > Isn't this now resolved? I think we can consider it resolved – I expect that we're still spending more cycles than java 8 when the ClassLoaderContextSelector (default) and AsyncLoggerContextSelector are used, but it's half as expensive as it was prior to my changes. BasicContextSelector and the new BasicAsyncLoggerContextSelector definitely solve the problem when they're used.

          Commit 86ce2e3dcff991a5a275383c282292ce0fb1cef6 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=86ce2e3 ]

          Fix incorrect LogManager accessor used by LOG4J2-2940

          The `getContext()` accessor with no args has been used as a fallback
          for Log4jLoggerFactory slf4j implementations for a while, but it's
          much more likely to be used now that LOG4J2-2940 is resolved.
          Without the `false` argument, the first slf4j LoggerFactory.getLogger
          call will not cause log4j to initialize itself.

          jira-bot ASF subversion and git services added a comment - Commit 86ce2e3dcff991a5a275383c282292ce0fb1cef6 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=86ce2e3 ] Fix incorrect LogManager accessor used by LOG4J2-2940 The `getContext()` accessor with no args has been used as a fallback for Log4jLoggerFactory slf4j implementations for a while, but it's much more likely to be used now that LOG4J2-2940 is resolved. Without the `false` argument, the first slf4j LoggerFactory.getLogger call will not cause log4j to initialize itself.

          Commit 86ce2e3dcff991a5a275383c282292ce0fb1cef6 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=86ce2e3 ]

          Fix incorrect LogManager accessor used by LOG4J2-2940

          The `getContext()` accessor with no args has been used as a fallback
          for Log4jLoggerFactory slf4j implementations for a while, but it's
          much more likely to be used now that LOG4J2-2940 is resolved.
          Without the `false` argument, the first slf4j LoggerFactory.getLogger
          call will not cause log4j to initialize itself.

          jira-bot ASF subversion and git services added a comment - Commit 86ce2e3dcff991a5a275383c282292ce0fb1cef6 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=86ce2e3 ] Fix incorrect LogManager accessor used by LOG4J2-2940 The `getContext()` accessor with no args has been used as a fallback for Log4jLoggerFactory slf4j implementations for a while, but it's much more likely to be used now that LOG4J2-2940 is resolved. Without the `false` argument, the first slf4j LoggerFactory.getLogger call will not cause log4j to initialize itself.

          Commit 97c89b9fa25042dec8d5d63ddcfb266c22d12d17 in logging-log4j2's branch refs/heads/master from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=97c89b9 ]

          Fix incorrect LogManager accessor used by LOG4J2-2940

          The `getContext()` accessor with no args has been used as a fallback
          for Log4jLoggerFactory slf4j implementations for a while, but it's
          much more likely to be used now that LOG4J2-2940 is resolved.
          Without the `false` argument, the first slf4j LoggerFactory.getLogger
          call will not cause log4j to initialize itself.

          jira-bot ASF subversion and git services added a comment - Commit 97c89b9fa25042dec8d5d63ddcfb266c22d12d17 in logging-log4j2's branch refs/heads/master from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=97c89b9 ] Fix incorrect LogManager accessor used by LOG4J2-2940 The `getContext()` accessor with no args has been used as a fallback for Log4jLoggerFactory slf4j implementations for a while, but it's much more likely to be used now that LOG4J2-2940 is resolved. Without the `false` argument, the first slf4j LoggerFactory.getLogger call will not cause log4j to initialize itself.

          Commit 97c89b9fa25042dec8d5d63ddcfb266c22d12d17 in logging-log4j2's branch refs/heads/master from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=97c89b9 ]

          Fix incorrect LogManager accessor used by LOG4J2-2940

          The `getContext()` accessor with no args has been used as a fallback
          for Log4jLoggerFactory slf4j implementations for a while, but it's
          much more likely to be used now that LOG4J2-2940 is resolved.
          Without the `false` argument, the first slf4j LoggerFactory.getLogger
          call will not cause log4j to initialize itself.

          jira-bot ASF subversion and git services added a comment - Commit 97c89b9fa25042dec8d5d63ddcfb266c22d12d17 in logging-log4j2's branch refs/heads/master from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=97c89b9 ] Fix incorrect LogManager accessor used by LOG4J2-2940 The `getContext()` accessor with no args has been used as a fallback for Log4jLoggerFactory slf4j implementations for a while, but it's much more likely to be used now that LOG4J2-2940 is resolved. Without the `false` argument, the first slf4j LoggerFactory.getLogger call will not cause log4j to initialize itself.

          Commit 97c89b9fa25042dec8d5d63ddcfb266c22d12d17 in logging-log4j2's branch refs/heads/mean-bean-machine from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=97c89b9 ]

          Fix incorrect LogManager accessor used by LOG4J2-2940

          The `getContext()` accessor with no args has been used as a fallback
          for Log4jLoggerFactory slf4j implementations for a while, but it's
          much more likely to be used now that LOG4J2-2940 is resolved.
          Without the `false` argument, the first slf4j LoggerFactory.getLogger
          call will not cause log4j to initialize itself.

          jira-bot ASF subversion and git services added a comment - Commit 97c89b9fa25042dec8d5d63ddcfb266c22d12d17 in logging-log4j2's branch refs/heads/mean-bean-machine from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=97c89b9 ] Fix incorrect LogManager accessor used by LOG4J2-2940 The `getContext()` accessor with no args has been used as a fallback for Log4jLoggerFactory slf4j implementations for a while, but it's much more likely to be used now that LOG4J2-2940 is resolved. Without the `false` argument, the first slf4j LoggerFactory.getLogger call will not cause log4j to initialize itself.

          Commit 97c89b9fa25042dec8d5d63ddcfb266c22d12d17 in logging-log4j2's branch refs/heads/mean-bean-machine from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=97c89b9 ]

          Fix incorrect LogManager accessor used by LOG4J2-2940

          The `getContext()` accessor with no args has been used as a fallback
          for Log4jLoggerFactory slf4j implementations for a while, but it's
          much more likely to be used now that LOG4J2-2940 is resolved.
          Without the `false` argument, the first slf4j LoggerFactory.getLogger
          call will not cause log4j to initialize itself.

          jira-bot ASF subversion and git services added a comment - Commit 97c89b9fa25042dec8d5d63ddcfb266c22d12d17 in logging-log4j2's branch refs/heads/mean-bean-machine from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=97c89b9 ] Fix incorrect LogManager accessor used by LOG4J2-2940 The `getContext()` accessor with no args has been used as a fallback for Log4jLoggerFactory slf4j implementations for a while, but it's much more likely to be used now that LOG4J2-2940 is resolved. Without the `false` argument, the first slf4j LoggerFactory.getLogger call will not cause log4j to initialize itself.

          Commit 86ce2e3dcff991a5a275383c282292ce0fb1cef6 in logging-log4j2's branch refs/heads/LOG4J2-3080 from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=86ce2e3 ]

          Fix incorrect LogManager accessor used by LOG4J2-2940

          The `getContext()` accessor with no args has been used as a fallback
          for Log4jLoggerFactory slf4j implementations for a while, but it's
          much more likely to be used now that LOG4J2-2940 is resolved.
          Without the `false` argument, the first slf4j LoggerFactory.getLogger
          call will not cause log4j to initialize itself.

          jira-bot ASF subversion and git services added a comment - Commit 86ce2e3dcff991a5a275383c282292ce0fb1cef6 in logging-log4j2's branch refs/heads/ LOG4J2-3080 from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=86ce2e3 ] Fix incorrect LogManager accessor used by LOG4J2-2940 The `getContext()` accessor with no args has been used as a fallback for Log4jLoggerFactory slf4j implementations for a while, but it's much more likely to be used now that LOG4J2-2940 is resolved. Without the `false` argument, the first slf4j LoggerFactory.getLogger call will not cause log4j to initialize itself.

          Commit 86ce2e3dcff991a5a275383c282292ce0fb1cef6 in logging-log4j2's branch refs/heads/LOG4J2-3080 from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=86ce2e3 ]

          Fix incorrect LogManager accessor used by LOG4J2-2940

          The `getContext()` accessor with no args has been used as a fallback
          for Log4jLoggerFactory slf4j implementations for a while, but it's
          much more likely to be used now that LOG4J2-2940 is resolved.
          Without the `false` argument, the first slf4j LoggerFactory.getLogger
          call will not cause log4j to initialize itself.

          jira-bot ASF subversion and git services added a comment - Commit 86ce2e3dcff991a5a275383c282292ce0fb1cef6 in logging-log4j2's branch refs/heads/ LOG4J2-3080 from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=86ce2e3 ] Fix incorrect LogManager accessor used by LOG4J2-2940 The `getContext()` accessor with no args has been used as a fallback for Log4jLoggerFactory slf4j implementations for a while, but it's much more likely to be used now that LOG4J2-2940 is resolved. Without the `false` argument, the first slf4j LoggerFactory.getLogger call will not cause log4j to initialize itself.

          Commit 59fd1f3f62e3c503c480a933ca360112be520a74 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=59fd1f3 ]

          Remove unreleased+replaced StackLocator API from LOG4J2-2940

          jira-bot ASF subversion and git services added a comment - Commit 59fd1f3f62e3c503c480a933ca360112be520a74 in logging-log4j2's branch refs/heads/release-2.x from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=59fd1f3 ] Remove unreleased+replaced StackLocator API from LOG4J2-2940

          Commit 25c7001f4609438aaca803b2b577aab565e1ccdf in logging-log4j2's branch refs/heads/master from Carter Kozak
          [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=25c7001 ]

          Remove unreleased+replaced StackLocator API from LOG4J2-2940

          jira-bot ASF subversion and git services added a comment - Commit 25c7001f4609438aaca803b2b577aab565e1ccdf in logging-log4j2's branch refs/heads/master from Carter Kozak [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=25c7001 ] Remove unreleased+replaced StackLocator API from LOG4J2-2940

          People

            rgoers Ralph Goers
            hostalp Peter H
            Votes:
            1 Vote for this issue
            Watchers:
            Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment