Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of jessh@ptc.com designates
 12.11.148.84 as permitted sender)
Message-ID: <4E011413.50706@ptc.com>
Date: Tue, 21 Jun 2011 16:58:43 -0500
From: Jess Holle <jessh@ptc.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
CC: Christopher Schultz <chris@christopherschultz.net>
Subject: Re: Slower start with Tomcat 7.0.14 and higher
References: <4DFF9B84.5000501@ptc.com> <4DFF9C81.2030107@apache.org>
 <4DFFA25E.3090405@ptc.com> <4DFFBD1F.4020204@christopherschultz.net>
 <4DFFC003.2030708@ptc.com> <4DFFC43E.7020209@christopherschultz.net>
 <4DFFFD78.5050404@ptc.com>
In-Reply-To: <4DFFFD78.5050404@ptc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org