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,
is way slower than its counterpart
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

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

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

View raw message