autostart for /admin - was Re: StandardClassLoader ?

[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: autostart for /admin - was Re: StandardClassLoader ?

[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 ?

[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 ?

[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 ?

[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