Re: JDK 11 and StackWalker Performance Issue

First, you don’t need to file an issue as it would be closed as a duplicate of LOG4J2-2940. Second, LOG4J2-2537 has nothing to do with this issue. Ralph > On Dec 18, 2020, at 3:05 PM, Sean McCauliff wrote: > > Before I go and file a ticket is this ticket related to this problem? > https://iss

Re: JDK 11 and StackWalker Performance Issue

Also, 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 determi

Re: JDK 11 and StackWalker Performance Issue

Before I go and file a ticket is this ticket related to this problem? https://issues.apache.org/jira/browse/LOG4J2-2537 I don't have that warning on the application output however. log4j2 version is 2.13.1 On Fri, Dec 18, 2020 at 1:41 PM Carter Kozak wrote: > If we made a change that results

Re: JDK 11 and StackWalker Performance Issue

This looks like the same issue as https://issues.apache.org/jira/browse/LOG4J2-2940 . The ClassLoaderContextSelector needs to find the caller’s class to determine which LoggerContext the Logger should be attached to. If you don’t want to have

Re: JDK 11 and StackWalker Performance Issue

If we made a change that results in degraded performance, we should investigate and fix it. I imagine this would have an impact on application startup time even if all loggers are loaded once as static fields. Can you confirm the log4j2 version that you're using in this example? It appears that

JDK 11 and StackWalker Performance Issue

There are many threads in our Kafka server performing logging. Their stacks look like the stack trace below. I see from other email threads that java.lang.StackWalker in JDK 11 is not as performant as the old sun.* classes that are used for the same functionality. Since this is logged at debug l