Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: StandardClassLoader ?
Date: Fri, 6 Aug 2004 13:12:30 -0400
Message-ID: <9C5166762F311146951505C6790A9CF80229BE3B@US-VS1.corp.mpi.com>
Thread-Topic: StandardClassLoader ?
Thread-Index: AcR71/ZP1NDQi59XS4iD4Y/GFEPPKwAAHg0g
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>


Hola,
FWIW, I think current startup time is reasonable.  Most serious apps w=
ill do stuff in their ServletContextListener#contextInitialized or Ser=
vlet#init methods that will eclipse the Tomcat startup time anyhow.  I=
 don't see it as an area of significant concern ;)

Yoav Shapira
Millennium Research Informatics


>-----Original Message-----
>From: Remy Maucherat [mailto:remm@apache.org]
>Sent: Friday, August 06, 2004 1:09 PM
>To: Tomcat Developers List
>Subject: Re: StandardClassLoader ?
>
>Costin Manolache wrote:
>
>> 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 abou=
t
>>>>> 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 - i=
s
>>>> to use some caches. For XML - you would need to make few of the
>>>> classes serializable, or create few wrappers that are serializabl=
e.
>>>> 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 ??=

>
>Try it without ;)
>
>> 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 ser=
ver ?
>
>I know, but it doesn't work right now (it's Struts' fault :( ). If yo=
u
>have ideas to make it work, then I'm obviously +1 for removing the
>load-on-startup thing.
>
>> Having "lazy loaded" webapps as a generic solution will help both
>> admin/ but also other infrequently used webapps. BTW - load-on-star=
tup
>> doesn't necesarily mean "server startup" ( at least that's my
>> understanding ), it means when the webapp is started.
>
>I don't think we can have that. It doesn't fit the way the other stuf=
f
>works (deployer, mapper).
>
>>
>>> 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 firs=
t
>> time and on web.xml change ).
>
>Yes, but the first time, it hurts ;)
>
>>
>>> 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.
>
>DOM is for server.xml. I don't think we need to save web.xml, right ?=

>
>>
>>
>>>
>>>> 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=3Dtrue...> ). URLClassLoader has this, but not our
>> findResourceInternal.
>>
>> But as you said - it's not a big priority.
>
>Yes, it should be added. This must be why the old StdCL performed wor=
se
>than the UCL.
>
>>
>>> 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 sy=
ncing.
>>
>> 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.
>
>Yes, it should, but I thought maybe we could get a little something h=
ere
>(and with all the funky URL stuff the URL CL does).
>
>>
>> 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.
>
>I agree. I'm kinda running out of optimization ideas, though (I don't=

>know if you profiled the regular request processing lately, but there=
's
>really nothing left). There doesn't seem to be too much which is doab=
le
>with the startup overall.
>
>R=E9my
>
>
>---------------------------------------------------------------------=

>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


This e-mail, including any attachments, is a confidential business com=
munication, and may contain information that is confidential, propriet=
ary and/or privileged.  This e-mail is intended only for the individua=
l(s) to whom it is addressed, and may not be saved, copied, printed, d=
isclosed or used by anyone else.  If you are not the(an) intended reci=
pient, please immediately delete this e-mail from your computer system=
 and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org