[
https://issues.apache.org/jira/browse/GEODE-8875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17276746#comment-17276746
]
ASF subversion and git services commented on GEODE-8875:
--------------------------------------------------------
Commit d058f0dd1f23a6339cd0860933e58e428cb9eea7 in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d058f0d ]
GEODE-8875: Removing packages element from log4j2 configuration file
This element causes log4j to scan all geode jars on startup. This slows down
the startup time of all geode processes, including gfsh.
It is not necessary because log4j has an annotation processor to generate a
config file that helps it find plugs that it needs.
> Geode is spending a lot of time in log4j classpath scanning on startup
> ----------------------------------------------------------------------
>
> Key: GEODE-8875
> URL: https://issues.apache.org/jira/browse/GEODE-8875
> Project: Geode
> Issue Type: Improvement
> Components: logging
> Reporter: Dan Smith
> Assignee: Dan Smith
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> When running gfsh, it takes a long time even to run the `gfsh help` command.
> For example, with our docker image it takes 10 seconds just to display the
> help from
> {code}
> docker run apachegeode/geode:latest time gfsh help
> {code}
> Doing some CPU sampling, it looks like the majority of the time is in log4j2
> scanning for plugins.
> {noformat}
> TRACE 300879: (thread=200001)
> java.lang.ClassLoader.defineClass1(ClassLoader.java:Unknown line)
> java.lang.ClassLoader.defineClass(ClassLoader.java:763)
>
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> java.net.URLClassLoader$1.run(URLClassLoader.java:363)
>
> java.security.AccessController.doPrivileged(AccessController.java:Unknown
> line)
> java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> org.apache.logging.log4j.core.config.plugins.util.ResolverUtil.addIfMatching(ResolverUtil.java:449)
>
> org.apache.logging.log4j.core.config.plugins.util.ResolverUtil.loadImplementationsInJar(ResolverUtil.java:351)
>
> org.apache.logging.log4j.core.config.plugins.util.ResolverUtil.findInPackage(ResolverUtil.java:233)
>
> org.apache.logging.log4j.core.config.plugins.util.PluginRegistry.loadFromPackage(PluginRegistry.java:221)
>
> org.apache.logging.log4j.core.config.plugins.util.PluginManager.collectPlugins(PluginManager.java:152)
>
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:224)
>
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:288)
>
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:579)
> {noformat}
> After further investigation, this scanning appears to be caused by this line
> in our log4j2-cli.xml file, which sets the packages to be "org.apache.geode"
> This causes log4j2 to scan all of our jar files.
> {code}
> <Configuration status="WARN" shutdownHook="disable"
> packages="org.apache.geode">
> {code}
> This scanning is completely unnecessary because log4j already has an
> annotation processor which generates a file that log4j2 can find without any
> scanning.
> This probably affects geode server startup, not just gfsh, because log4j2.xml
> has this setting as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
