On 22.06.2011 19:20, Jess Holle wrote:
> On 6/22/2011 10:16 AM, Jess Holle wrote:
> The only issue I found at this level is that both
> tomcat-juli-adapters.jar and tomcat-juli-adapters.jar are scanned. I'd
> think that all the Tomcat "extras" jars should be in Tomcat's
> out-of-the-box list of ja
On 6/22/2011 12:44 PM, Caldarale, Charles R wrote:
I think it can happen, without detection, if you have the same class directly
visible to multiple classloaders - which I recall that you do (but perhaps I
misunderstood this statement: "the base classloader includes a lot more than
CATALINA_BA
> From: Jess Holle [mailto:je...@ptc.com]
> Subject: Re: Slower start with Tomcat 7.0.14 and higher
> Since delegation is downwards
Only for the webapp classloader.
> the only issue that should possibly occur is if a class gets
> loaded in the parent classloader that then n
arale, Charles R wrote:
From: Jess Holle [mailto:je...@ptc.com]
Subject: Re: Slower start with Tomcat 7.0.14 and higher
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
I think we
> From: Jess Holle [mailto:je...@ptc.com]
> Subject: Re: Slower start with Tomcat 7.0.14 and higher
> 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
On 6/22/2011 10:16 AM, Jess Holle wrote:
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
a
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 ja
On 22/06/2011 15:08, Mark Thomas wrote:
> 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
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
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 wi
On 6/20/2011 5:05 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 6/20/2011 5:47 PM, Jess Holle wrote:
On 6/20/2011 4:35 PM, Christopher Schultz wrote:
Maybe you could move /some/ of them?
The libraries in question are actually loaded by the application
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 6/20/2011 5:47 PM, Jess Holle wrote:
> On 6/20/2011 4:35 PM, Christopher Schultz wrote:
>>
>> Maybe you could move /some/ of them?
>
> The libraries in question are actually loaded by the application
> classloader -- as is Tomcat's Bootstrap
On 6/20/2011 4:35 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 6/20/2011 3:41 PM, Jess Holle wrote:
On 6/20/2011 2:16 PM, Mark Thomas wrote:
It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 6/20/2011 3:41 PM, Jess Holle wrote:
> On 6/20/2011 2:16 PM, Mark Thomas wrote:
>> It should have improved for the majority of use cases in 7.0.14 but at
>> the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
>> 7.0.16 should h
On 6/20/2011 3:16 PM, Rainer Jung wrote:
Sure we want to make scaning as fast as possible. But did you realize,
that you can exclude Jars from being scanned? There's a list f
exclusions defined in catalina.properties.
Yes -- and I'll go there is the speed from 7.0.12 (which was quite
reasonable
On 6/20/2011 2:41 PM, Jess Holle wrote:
On 6/20/2011 2:16 PM, Mark Thomas wrote:
It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
to t
On 20.06.2011 21:41, Jess Holle wrote:
> On 6/20/2011 2:16 PM, Mark Thomas wrote:
>> It should have improved for the majority of use cases in 7.0.14 but at
>> the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
>> 7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/l
On 6/20/2011 2:16 PM, Mark Thomas wrote:
It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
to the pre 7.0.14 performance levels.
We're e
On 20/06/2011 20:12, Jess Holle wrote:
> Start up takes around 20 seconds longer with Tomcat 7.0.14 and 7.0.16
> than it did with 7.0.12.
>
> This appears to be due to time spent scanning jars for annotations,
> etc. We have a number of /very /large jar files in both the base
> classloader for To
Start up takes around 20 seconds longer with Tomcat 7.0.14 and 7.0.16
than it did with 7.0.12.
This appears to be due to time spent scanning jars for annotations,
etc. We have a number of /very /large jar files in both the base
classloader for Tomcat (which we're embedding) and in our web app
20 matches
Mail list logo
