tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Slower start with Tomcat 7.0.14 and higher
Date Wed, 22 Jun 2011 14:08:10 GMT
On 21/06/2011 22:58, Jess Holle wrote:
> If I alter JarFactory to always use FileUrlJar, then my startup is
> around 20 seconds faster, i.e. the speed is fully back to that of 7.0.12.
> It turns out the issue is the large jars I have in my WEB-INF/lib
> directory -- and FileUrlJar is still much faster in this case than using
> UrlJar even with a JNDI URL.

Interesting. I'll dig into this some more.

> Another issue is that WEB-INF/lib is visible to the parent classloader
> embedding Tomcat and to Tomcat as part of the web application and thus
> I'm probably getting double scanning -- though really Tomcat should be
> avoiding this by detecting that the same jar file is involved in both
> cases.  The reasons for the duplication in this classpath are long and
> historic.  Overall I'd rather not try to unwind this now.  I'd
> hope/assume that an annotation on a class, e.g. a filter annotation,
> would only result in one filter instance irrespective of how many times
> that class is visible to the classloader(s) in question.

That sounds like it might cause trouble. Classes are identified by the
combination of name and class loader so the same class loaded in two
different class loaders is treated as a different class. If both the web
application class loader and its parent class loader can see WEB-INF/lib
I can image all sorts of things may go wrong.

> Given that the JNDI node maps to a file if the web app is expanded -- as
> mine always is (being deployed originally as an expanded directory in
> .war layout not as a .ware archive), it seems there should be a "back
> door" for Tomcat to notice this and simply use the file location to
> begin with rather than doing any extra temporary file shenanigans in any
> case.  The JNDI wrapping is nice and all, but shouldn't cause a
> substantially sub-optimal performance approach when it is clear enough
> how to attain the appropriate File object.

It should be doing that already. I'll double check.

> Is there any danger -- other than worse performance in use cases I don't
> have -- in me patching my own Tomcat to always use FileUrlJar?  Should
> this perhaps be a config option?  Or possibly a config option based on
> file size?  [FileUrlJar may only be faster for larger jars from what
> little I know...]

That local patch should be safe. In terms of config, I'd like to keep
this as automated as possible. More research required.

For reference, how big are the JAR files we are talking about here?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message