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.
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.
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.
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...]
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
