Philipp Hedwig created LOG4J2-393:
-------------------------------------
Summary: Low intialization performance when using Log4J with jar
packages
Key: LOG4J2-393
URL: https://issues.apache.org/jira/browse/LOG4J2-393
Project: Log4j 2
Issue Type: Bug
Components: Configurators, Core
Affects Versions: 2.0-beta8
Reporter: Philipp Hedwig
We discovered a huge performance difference when initializing Log4J with
deployed jar packages compared to using it directly with normal class files.
As it seems,
_org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInJar_
is way slower than its counterpart
_org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInDirectory_
and since this method gets called a few hundred times at initialization in this
project, initialization of Log4J took more than 2 minutes with jar packages,
compared to a few seconds with class files.
The performance issue was already mentioned in
[LOG4J2-184|https://issues.apache.org/jira/browse/LOG4J2-184], only without the
jar problem.
The solution to [LOG4J2-175|https://issues.apache.org/jira/browse/LOG4J2-175]
might cause this, but we are unsure why the methods exactly get called this
often.
I just can tell that
_org.apache.logging.log4j.core.config.plugins.PluginManager#collectPlugins()_
gets called VERY often via
_org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_,
which gets called by
_org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_
And _collectPlugins()_ is remapped to _collectPlugins(boolean preLoad, final
String pkgs)_ with _collectPlugins(true, null);_. I'm unsure what this preLoad
is for, since it gets overridden with false and apparently no kind of caching
is used. In this method, _resolver.findInPackage(test, pkg);_ takes a whole lot
of time searching within the jars, as described in the beginning.
The only way to work around this was for us to extract the custom appender in a
sperate ant build target, and with this in a seperate jar, to minimize the size
of the jar, reducing the search time.
Can you cache things and maybe reduce the calls to _collectPlugins()_? I don't
see the probability of changing plugins during initialization as described in
LOG4J2-175 or the comment in
_org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_.
Introducing a variable for the plugin manager within the for loop in
_org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_
might be a good idea!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
