Re: autostart for /admin - was Re: StandardClassLoader ?
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 1 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: autostart for /admin - was Re: StandardClassLoader ?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: autostart for /admin - was Re: StandardClassLoader ?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: autostart for /admin - was Re: StandardClassLoader ?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
autostart for /admin - was Re: StandardClassLoader ?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
