tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: Slower start with Tomcat 7.0.14 and higher
Date Wed, 22 Jun 2011 15:16:46 GMT
On 6/22/2011 9:08 AM, Mark Thomas wrote:
>> 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.
Well the classloaders are clearly hierarchical, so only one Class 
instance is loaded.  The fact that both ClassLoaders can see the jar 
does not result in 2 Class objects -- nor should it result in an 
annotation being applied multiple times.  The jars are in fact exactly 
the same here -- as one of the web app's WEB-INF/lib directories is 
visible to the parent classloader.  It may be possible to move the jars 
somewhere else so that they're only part of the parent classloader, but 
that will require more reshuffling of the longstanding configuration.
>> 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?
They range in size from 48K to 46MB.  Only 3 jars are over 25MB in size.

Jess Holle

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message