You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2013/09/05 19:28:51 UTC
[jira] [Commented] (LOG4J2-393) Low initialization performance when
using Log4J with jar packages
[ https://issues.apache.org/jira/browse/LOG4J2-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759241#comment-13759241 ]
Ralph Goers commented on LOG4J2-393:
------------------------------------
I was actually looking at that recently. Originally, getPluginManager returned a cached object. Somewhere along the lines that was changed to allow new packages to be added. I think it needs to be made a little smarter to only create a new PluginManager if the packages have actually changed.
Using a variable in constructHierarchy also seems like a very good idea.
> Low initialization 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
> Labels: performance
>
> 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