tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: StandardClassLoader ?
Date Fri, 06 Aug 2004 15:17:47 GMT
Remy Maucherat wrote:

> Costin Manolache wrote:
>> Remy Maucherat wrote:
>>>  From my profile, the bottleneck for the startup time is XML parsing 
>>> and accessing entries in JARs (we can't do anything about that), with a 
>> Did you try a pull parser ? kxml2 is really fast and only 42K :-)
>> The other approach - which I think may have a lot of benefits - is to 
>> use some caches. For XML - you would need to make few of the classes 
>> serializable, or create few wrappers that are serializable.  And 
>> whenver a change is detected - reparse. Not trivial code, but you can 
>> get a lot
>> in cutting server.xml and web.xml parsing.
> The time is mostly parsing web.xml. However, it's nothing when compared 
> to starting certain webapps (such as the admin webapp), where *one* 
> webapp takes more time than starting up the rest of Tomcat (including 
> all the simple webapps, JMX and the modeler descriptors, etc).

Does it really need "load-on-startup" for its ApplicationServlet ??
Do we really need to load /admin on startup ? Most people never use it,
or use it only ocasionally. How many times do you configure the server ?

Having "lazy loaded" webapps as a generic solution will help both admin/ 
but also other infrequently used webapps. BTW - load-on-startup doesn't 
necesarily mean "server startup" ( at least that's my understanding ), 
it means when the webapp is started.

> The other big problem is the (needed) JAR parsing for TLDs during the 
> deployment of a webapp.

I tought we already have some code to cache the tlds and avoid 
reparsing. This could be extended to the entire web.xml, and if we do 
this - probably validation can be on ( since it'll happen only first 
time and on web.xml change ).

> Classloding and XML parsing are negligible when compared to these two 
> things. So why bother ?

You're right.

> If I do the server.xml persistence that I envision, I'm using DOM for 
> everything anyway.

Well, you can use DOM for web.xml - but you need DOM only when changing 
settings, so you can also create the dom lazy, and use the .ser form
on regular startup.

>> The jar index is also quite usefull IMO (  is it implemented in
>> WebappClassLoader ? I can't find any code ).
> No, there's no index. I think it could be useful (mark that some 
> packages are available in some JARs).

I was talking about the JDK1.4 index ( we already have <jar 
index=true...> ). URLClassLoader has this, but not our findResourceInternal.

But as you said - it's not a big priority.

> The thing I was planning to try just in case for StdCL was to load 
> everything on creation of the classloader. Since in the end most classes 
> will be loaded on startup, it would remove the need for syncing.

Do you think syncing is a big problem ? Most of the time it should be a 
free lock, and that is supposed to be reasonably fast.

I'm curious how JDK1.5 support for multiple processes works and if we 
could get some classes shared / cached.

In any case - unless loading classes on startup without sync has a big
perf. improvement, I think it may be better to do the other 
optimizations first.


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

View raw message