You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2004/08/05 08:12:19 UTC
StandardClassLoader ?
Is there any reason we still need StandardClassLoader ? It seems it is
only used once, in ClassLoaderFactory, and it is used exactly like a
regular URLClassLoader - the only thing that needs to be moved is the
convert() method. The code itself is just debug and duplication of
URLClassLoader - the reverse loading is not used and it's not even
really implemented in all parts of the code.
It would reduce in half the complexity in the loader package :-), and
it would make 'embeded' and 'standalone' more similar ( embeded doesn't
usually use Bootstrap and StandardClassLoader but the embedding app loader).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Session Management Question
Posted by Michael Watson <mi...@estafet.com>.
Hi All,
This may have been answered elsewhere in the past but I'm struggling to find
it if it has - though please point me in the direction of past answers if
that's the case.
I'm trying to understand how a single instance of Tomcat manages sessions.
Is there any pooling/recycling of sesssion objects or are they
created/destroyed as required?
If they are pooled, is the size of this pool configurable?
Also where can I find some good documentation on managing sessions across a
cluster or load balanced instances?
Does anyone know of a practical limit for the number of concurrent
connections Tomcat can cope with on a reasonably out of the box Redhat
installation (obviously file descriptor limits aside)?
I realise this is more of a user question, but I figure members of this list
are more likely to be able to provide me with the level of detail I'm
looking for.
Any info you can supply would be much appreciated (I also need to find this
out with some urgency)
Thanks in advance
Mike
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.709 / Virus Database: 465 - Release Date: 22/06/2004
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: autostart for /admin - was Re: StandardClassLoader ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Remy Maucherat wrote:
>>
>>>> BTW, does the spec says that the form login page is excluded from
>>>> filters ??
>>>
>>>
>>> That's undefined, as it's some kind of internal dispatching of the
>>> container. It seemed reasonable trying to do it with a RD forward.
>>
>>
>> Well, if I have a filter on /* and / ( and I added for *.jsp, *.do and
>> anything I could think of ) - I tought it'll be invoked for all
>> requests in that context. Even if it is forwarded.
>
>
> Well, no. different invocation is a separate mapping (INCLUDE, FORWARD,
> etc; and no, there's no ALL mapping ;) ).
Feel free to redirect me to tomcat-user :-), but is there any way to
filter the form login page, or is it un-filtrable ?
If it is included/forwarded/etc - it should be included from somewhere,
and a filter would apply there. From what I see in the code, the form
login happens before the filters - so I'm starting to understand why it
doesn't work, but from a spec point a view, it looks like a small bug.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: autostart for /admin - was Re: StandardClassLoader ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>>> BTW, does the spec says that the form login page is excluded from
>>> filters ??
>>
>> That's undefined, as it's some kind of internal dispatching of the
>> container. It seemed reasonable trying to do it with a RD forward.
>
> Well, if I have a filter on /* and / ( and I added for *.jsp, *.do and
> anything I could think of ) - I tought it'll be invoked for all
> requests in that context. Even if it is forwarded.
Well, no. different invocation is a separate mapping (INCLUDE, FORWARD,
etc; and no, there's no ALL mapping ;) ).
>> I don't really see what it changes for production servers: if
>> something as heavy as the admin webapp starts up, it's going to kill
>> the server performance. I agree delaying webapp startup would give a
>> better impression of performance, but it would be actually bad for a
>> number of configurations.
>
> True. The lazy loading should be paired with automatic unloading/sleep
> of apps not used recently - again, based on config. In most servers I
> know, a small number of webapps are used most of the time, and the
> most webapps are almost never used, or just for very short time. Well
> - that's just an idea, I don't have an immediate itch for this one. I
> am impressed with Eclipse plugin architecture - and the way they
> manage the memory.
Ah ok.
Well, we could try to be progressivly adding these new features to the
new branch, since I assume it would stay as
stable-but-with-significant-feature-additions for some time.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: autostart for /admin - was Re: StandardClassLoader ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>> One simple solution is to add
>>
>> <% // Force the initialization of "action" servlet
>> RequestDispatcher
>> actionS=getServletContext().getNamedDispatcher("action").include(request,response);
>>
>> %>
>>
>> in login.jsp
>
>
> This seems good enough already.
Ok, I'll check it in then after I figure out why the filter didn't work,
>> A better solution is to add a small filter that will make sure struts
>> is initialized. However that doesn't seem to work with login.jsp - the
>> filter is not called ( I tried explicit match, by name, etc ).
>
>
> login.jsp is a forward. Did you try mapping the filter on a forward ?
>
>> BTW, does the spec says that the form login page is excluded from
>> filters ??
>
>
> That's undefined, as it's some kind of internal dispatching of the
> container. It seemed reasonable trying to do it with a RD forward.
Well, if I have a filter on /* and / ( and I added for *.jsp, *.do and
anything I could think of ) - I tought it'll be invoked for all requests
in that context. Even if it is forwarded.
> I don't really see what it changes for production servers: if something
> as heavy as the admin webapp starts up, it's going to kill the server
> performance. I agree delaying webapp startup would give a better
> impression of performance, but it would be actually bad for a number of
> configurations.
True. The lazy loading should be paired with automatic unloading/sleep
of apps not used recently - again, based on config. In most servers I
know, a small number of webapps are used most of the time, and the most
webapps are almost never used, or just for very short time. Well -
that's just an idea, I don't have an immediate itch for this one. I am
impressed with Eclipse plugin architecture - and the way they manage the
memory.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: autostart for /admin - was Re: StandardClassLoader ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>>>> 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 ;)
>
>
> I tried.
>
>>
>>> 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 ?
>>
>>
>>
>> I know, but it doesn't work right now (it's Struts' fault :( ). If
>> you have ideas to make it work, then I'm obviously +1 for removing
>> the load-on-startup thing.
>
>
>
> One simple solution is to add
>
> <% // Force the initialization of "action" servlet
> RequestDispatcher
> actionS=getServletContext().getNamedDispatcher("action").include(request,response);
>
> %>
>
> in login.jsp
This seems good enough already.
>
> A better solution is to add a small filter that will make sure struts
> is initialized. However that doesn't seem to work with login.jsp - the
> filter is not called ( I tried explicit match, by name, etc ).
login.jsp is a forward. Did you try mapping the filter on a forward ?
> BTW, does the spec says that the form login page is excluded from
> filters ??
That's undefined, as it's some kind of internal dispatching of the
container. It seemed reasonable trying to do it with a RD forward.
> I can check in both the filter and the small hack to login.jsp, it
> seems to work fine.
>
>>
>>> 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.
>>
>>
>>
>> I don't think we can have that. It doesn't fit the way the other
>> stuff works (deployer, mapper).
>
>
> Well, the mapper is already able to deal with webapps that are
> removed/added/reloaded.
>
> A "lazy loaded" app is like an app that has a single mapping, /* -
> mapped to a lazy-load action that will read web.xml and add the other
> mappings.
>
> I think it's a very reasonable use case - performance is not only
> about HelloWorld response time, but also about hosting 1000s small (
> and infrequently used ) apps. Apache can handle very large numbers of
> virtual hosts and apps.
>
>>> 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 ?
>
>
> Well, that's a big discussion, let's leave it for another time :-)
>
>
>
>
>>
>> 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 doable with the startup overall.
>
>
> See above. I ran out of ideas for the basic path long ago ( or at
> least out of interest :-), it is more than enough for most uses.
>
> Optimizations for the other direction - very larger number of
> apps/vhosts - are more interesting. So is optimizing the uptime -
> having tomcat never need a restart is sometimes better than slightly
> better startup time.
I did a lot already for the "10000 webapps" use case, for example
removing the need for one backgroud thread per webapp in 5.0.x.
I don't really see what it changes for production servers: if something
as heavy as the admin webapp starts up, it's going to kill the server
performance. I agree delaying webapp startup would give a better
impression of performance, but it would be actually bad for a number of
configurations.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
autostart for /admin - was Re: StandardClassLoader ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>>> 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 ;)
I tried.
>
>> 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 ?
>
>
> I know, but it doesn't work right now (it's Struts' fault :( ). If you
> have ideas to make it work, then I'm obviously +1 for removing the
> load-on-startup thing.
One simple solution is to add
<% // Force the initialization of "action" servlet
RequestDispatcher
actionS=getServletContext().getNamedDispatcher("action").include(request,response);
%>
in login.jsp
A better solution is to add a small filter that will make sure struts is
initialized. However that doesn't seem to work with login.jsp - the
filter is not called ( I tried explicit match, by name, etc ).
BTW, does the spec says that the form login page is excluded from filters ??
I can check in both the filter and the small hack to login.jsp, it seems
to work fine.
>
>> 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.
>
>
> I don't think we can have that. It doesn't fit the way the other stuff
> works (deployer, mapper).
Well, the mapper is already able to deal with webapps that are
removed/added/reloaded.
A "lazy loaded" app is like an app that has a single mapping, /* -
mapped to a lazy-load action that will read web.xml and add the other
mappings.
I think it's a very reasonable use case - performance is not only about
HelloWorld response time, but also about hosting 1000s small ( and
infrequently used ) apps. Apache can handle very large numbers of
virtual hosts and apps.
>> 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 ?
Well, that's a big discussion, let's leave it for another time :-)
>
> 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 doable
> with the startup overall.
See above. I ran out of ideas for the basic path long ago ( or at least
out of interest :-), it is more than enough for most uses.
Optimizations for the other direction - very larger number of
apps/vhosts - are more interesting. So is optimizing the uptime - having
tomcat never need a restart is sometimes better than slightly better
startup time.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Brian Pane <br...@apache.org>.
Remy Maucherat wrote:
> 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 doable with the startup overall.
I've found that the parsing of the default server.xml during Tomcat
5.0.27 startup takes 1.5 seconds on my test system. In comparison,
the SAX-based element-counter sample program shipped with Xerces-J
takes less than 100 ms to parse the same file on the same hardware.
Based on this, my hypothesis is that the SAX callback handlers in
org.apache.tomcat.util.digester.Digester may account for a lot of
the parsing time. Does that match what you've found in your profiling?
(I only have coarse-grained profiling data from adding
System#currentTimeMillis calls to the Tomcat code. I haven't yet
figured out how to use "-Xrunhprof" without slowing Tomcat to a crawl.)
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Remy Maucherat <re...@apache.org>.
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 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 ??
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 server ?
I know, but it doesn't work right now (it's Struts' fault :( ). If you
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-startup
> 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 stuff
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 first
> 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=true...> ). 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 worse
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 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.
Yes, it should, but I thought maybe we could get a little something here
(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 doable
with the startup overall.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Costin Manolache <cm...@yahoo.com>.
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.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Remy Maucherat <re...@apache.org>.
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).
The other big problem is the (needed) JAR parsing for TLDs during the
deployment of a webapp.
Classloding and XML parsing are negligible when compared to these two
things. So why bother ?
If I do the server.xml persistence that I envision, I'm using DOM for
everything anyway.
> 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).
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.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Costin Manolache <cm...@yahoo.com>.
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 jar index is also quite usefull IMO ( is it implemented in
WebappClassLoader ? I can't find any code ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Filip Hanik - Dev <de...@hanik.com>.
>You could enable delegation to the parent CL, if it fits
>your needs better.
yup, it does this already. I totally missed that we are talking CL at startup time,
in this case it doesn't really matter.
Filip
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, August 05, 2004 12:48 PM
Subject: Re: StandardClassLoader ?
Filip Hanik - Dev wrote:
>here is the huge performance boost:
>
>Every single time I deserialized an object, it has to do a cl.loadClass(),
>now using a custom object stream, it would search the WCL first, then the SCL. And since it didn't exist in WCL, it still seemed to
>do a long scan each time, and then defaulting back to SCL at which point it was fast.
>
>By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe told me, I trust him :)
>Is this scenario clear?
>
>
I do understand it. However, I don't quite see a big problem, as most of
the application stuff should be application types, except the wrapper
session object. You could enable delegation to the parent CL, if it fits
your needs better.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev wrote:
>here is the huge performance boost:
>
>Every single time I deserialized an object, it has to do a cl.loadClass(),
>now using a custom object stream, it would search the WCL first, then the SCL. And since it didn't exist in WCL, it still seemed to
>do a long scan each time, and then defaulting back to SCL at which point it was fast.
>
>By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe told me, I trust him :)
>Is this scenario clear?
>
>
I do understand it. However, I don't quite see a big problem, as most of
the application stuff should be application types, except the wrapper
session object. You could enable delegation to the parent CL, if it fits
your needs better.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Filip Hanik - Dev <de...@hanik.com>.
> From my profile, the bottleneck for the startup time is XML
also I missed this one, startup time...my scenario is a dynamic one where some webapps have 20+ libraries in the WCL
Filip
----- Original Message -----
From: "Filip Hanik - Dev" <de...@hanik.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, August 05, 2004 12:37 PM
Subject: Re: StandardClassLoader ?
here is the huge performance boost:
Every single time I deserialized an object, it has to do a cl.loadClass(),
now using a custom object stream, it would search the WCL first, then the SCL. And since it didn't exist in WCL, it still seemed to
do a long scan each time, and then defaulting back to SCL at which point it was fast.
By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe told me, I trust him :)
Is this scenario clear?
Filip
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, August 05, 2004 11:01 AM
Subject: Re: StandardClassLoader ?
Filip Hanik - Dev wrote:
>During session replication I optimized my code to decide what order class loader to use based on the class name.
>
>For example, if you load a class that starts with org.apache.catalina. I attempt to load it with the SCL first, it gave the app a
>huge performance boost.
>
>I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts you can make, like make a list of all the
>classes in common/lib and server/lib and never load those through WebCL unless specified by the user. Most user would love the
>performance gain of this, and the ability to turn it on/off
>
>
This is extremely easy to test: you need to add stuff to the package
array in WCL, so that it will delegate for these packages. This doesn't
improve performance in any noticeable way (as I expected), so I don't
see where you found any huge performance boost. While it does sound
great, I think your test seemed either bad or very specific.
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
little for classloading as well (but it's not very big, and my
optimization plans were to experiment loading everything at once on
stratup, to be able to remove all syncing in the CL - I don't even know
if that would have been efficient, and since it does conflict with the
more interesting stuff from Costin, I'm giving up on that one for now).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Filip Hanik - Dev <de...@hanik.com>.
here is the huge performance boost:
Every single time I deserialized an object, it has to do a cl.loadClass(),
now using a custom object stream, it would search the WCL first, then the SCL. And since it didn't exist in WCL, it still seemed to
do a long scan each time, and then defaulting back to SCL at which point it was fast.
By bypassing the WCL check, knowing the class didn't exist there, it was a lot faster. JProbe told me, I trust him :)
Is this scenario clear?
Filip
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, August 05, 2004 11:01 AM
Subject: Re: StandardClassLoader ?
Filip Hanik - Dev wrote:
>During session replication I optimized my code to decide what order class loader to use based on the class name.
>
>For example, if you load a class that starts with org.apache.catalina. I attempt to load it with the SCL first, it gave the app a
>huge performance boost.
>
>I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts you can make, like make a list of all the
>classes in common/lib and server/lib and never load those through WebCL unless specified by the user. Most user would love the
>performance gain of this, and the ability to turn it on/off
>
>
This is extremely easy to test: you need to add stuff to the package
array in WCL, so that it will delegate for these packages. This doesn't
improve performance in any noticeable way (as I expected), so I don't
see where you found any huge performance boost. While it does sound
great, I think your test seemed either bad or very specific.
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
little for classloading as well (but it's not very big, and my
optimization plans were to experiment loading everything at once on
stratup, to be able to remove all syncing in the CL - I don't even know
if that would have been efficient, and since it does conflict with the
more interesting stuff from Costin, I'm giving up on that one for now).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev wrote:
>During session replication I optimized my code to decide what order class loader to use based on the class name.
>
>For example, if you load a class that starts with org.apache.catalina. I attempt to load it with the SCL first, it gave the app a
>huge performance boost.
>
>I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts you can make, like make a list of all the
>classes in common/lib and server/lib and never load those through WebCL unless specified by the user. Most user would love the
>performance gain of this, and the ability to turn it on/off
>
>
This is extremely easy to test: you need to add stuff to the package
array in WCL, so that it will delegate for these packages. This doesn't
improve performance in any noticeable way (as I expected), so I don't
see where you found any huge performance boost. While it does sound
great, I think your test seemed either bad or very specific.
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
little for classloading as well (but it's not very big, and my
optimization plans were to experiment loading everything at once on
stratup, to be able to remove all syncing in the CL - I don't even know
if that would have been efficient, and since it does conflict with the
more interesting stuff from Costin, I'm giving up on that one for now).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Filip Hanik - Dev <de...@hanik.com>.
During session replication I optimized my code to decide what order class loader to use based on the class name.
For example, if you load a class that starts with org.apache.catalina. I attempt to load it with the SCL first, it gave the app a
huge performance boost.
I know I know, this breaks the rule of thumb with webapps, but there are smart shortcuts you can make, like make a list of all the
classes in common/lib and server/lib and never load those through WebCL unless specified by the user. Most user would love the
performance gain of this, and the ability to turn it on/off
Filip
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Thursday, August 05, 2004 9:54 AM
Subject: Re: StandardClassLoader ?
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Is there any reason we still need StandardClassLoader ? It seems it is
>> only used once, in ClassLoaderFactory, and it is used exactly like a
>> regular URLClassLoader - the only thing that needs to be moved is the
>> convert() method. The code itself is just debug and duplication of
>> URLClassLoader - the reverse loading is not used and it's not even
>> really implemented in all parts of the code.
>
>
> I'll keep it for now, since I'll try experiments to try to have faster
> classloading. If my stuff isn't efficient, then I'll remove it.
Can you experiment with WebappClassLoader instead :-) ? SCL is only used
in standalone mode and only for loading internal classes. And removing
it will improve class loading time by itself - one less layer of if()
and indirections.
( I'm experimenting with class loading too, and it's easier to do it in
one loader )
What I'm trying to do is allow some modules ( connectors, auth, etc ) to
be deployed and loaded/unloaded/upgraded at runtime.
Costin
>
>>
>> It would reduce in half the complexity in the loader package :-), and
>> it would make 'embeded' and 'standalone' more similar ( embeded doesn't
>> usually use Bootstrap and StandardClassLoader but the embedding app
>> loader).
>
>
> Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Can you experiment with WebappClassLoader instead :-) ? SCL is only used
>> in standalone mode and only for loading internal classes. And removing
>> it will improve class loading time by itself - one less layer of if()
>> and indirections.
>>
>> ( I'm experimenting with class loading too, and it's easier to do it
>> in one loader )
>>
>> What I'm trying to do is allow some modules ( connectors, auth, etc )
>> to be deployed and loaded/unloaded/upgraded at runtime.
>
>
> That's not at all what I've planned (something really simple, not at all
> adding features or new capabilities). UCL works indeed better than SCL,
> so I removed it.
Technically it's not a "new" feature, it is a very old one ( it was
implemented in 3.3 :-).
Right now if you want to dynamically add or update a connector - you
need to restart tomcat. Even if it is embedded in jboss ( but at least
you don't have to take down the entire server, only the tomcat module ).
While UCL has great features, we can't take advantage of any of them,
because our class loading is too rigid.
That's even worse in webapps - where all you can do is place some jars
in shared/ or have no common libs at all. No easy way to use features
from the embedding container.
> I'm moving to the next item in my list (I think package renaming and
> repackaging of the dependencies: commons-dbcp and Ant).
If you don't mind, I'll keep playing with the WebClassLoader, if adding
such a feature is unacceptable then at least I would like to add some
hooks to allow use of a different loader implementation.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Can you experiment with WebappClassLoader instead :-) ? SCL is only used
> in standalone mode and only for loading internal classes. And removing
> it will improve class loading time by itself - one less layer of if()
> and indirections.
>
> ( I'm experimenting with class loading too, and it's easier to do it
> in one loader )
>
> What I'm trying to do is allow some modules ( connectors, auth, etc )
> to be deployed and loaded/unloaded/upgraded at runtime.
That's not at all what I've planned (something really simple, not at all
adding features or new capabilities). UCL works indeed better than SCL,
so I removed it.
I'm moving to the next item in my list (I think package renaming and
repackaging of the dependencies: commons-dbcp and Ant).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Is there any reason we still need StandardClassLoader ? It seems it is
>> only used once, in ClassLoaderFactory, and it is used exactly like a
>> regular URLClassLoader - the only thing that needs to be moved is the
>> convert() method. The code itself is just debug and duplication of
>> URLClassLoader - the reverse loading is not used and it's not even
>> really implemented in all parts of the code.
>
>
> I'll keep it for now, since I'll try experiments to try to have faster
> classloading. If my stuff isn't efficient, then I'll remove it.
Can you experiment with WebappClassLoader instead :-) ? SCL is only used
in standalone mode and only for loading internal classes. And removing
it will improve class loading time by itself - one less layer of if()
and indirections.
( I'm experimenting with class loading too, and it's easier to do it in
one loader )
What I'm trying to do is allow some modules ( connectors, auth, etc ) to
be deployed and loaded/unloaded/upgraded at runtime.
Costin
>
>>
>> It would reduce in half the complexity in the loader package :-), and
>> it would make 'embeded' and 'standalone' more similar ( embeded doesn't
>> usually use Bootstrap and StandardClassLoader but the embedding app
>> loader).
>
>
> Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: StandardClassLoader ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Is there any reason we still need StandardClassLoader ? It seems it is
> only used once, in ClassLoaderFactory, and it is used exactly like a
> regular URLClassLoader - the only thing that needs to be moved is the
> convert() method. The code itself is just debug and duplication of
> URLClassLoader - the reverse loading is not used and it's not even
> really implemented in all parts of the code.
I'll keep it for now, since I'll try experiments to try to have faster
classloading. If my stuff isn't efficient, then I'll remove it.
>
> It would reduce in half the complexity in the loader package :-), and
> it would make 'embeded' and 'standalone' more similar ( embeded doesn't
> usually use Bootstrap and StandardClassLoader but the embedding app
> loader).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org