logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philipp Hedwig (JIRA)" <j...@apache.org>
Subject [jira] [Created] (LOG4J2-393) Low intialization performance when using Log4J with jar packages
Date Thu, 05 Sep 2013 16:12:51 GMT
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message