On Wed, Mar 10, 2010 at 10:28 PM, Mladen Turk <mt...@apache.org> wrote:
> On 03/10/2010 11:10 PM, Costin Manolache wrote: > >> You want to have each webapp served by a different process ? >> Or even different versions of a webapp in a different process ? >> >> > First goal is to get rid of connectors and use Tomcat > directly inside httpd or IIS or new Commons Runtime > (replacing Tomcat Native and Daemon) I'm working on. > It used to work - about 10 years ago :-) > Second is to have application pools where one could > say: Serve WebAppX inside Default Application Pool > consisting of 1 ... N processes or use Custom Application > pool with some process limitation factors (memory, cpu usage, etc) > This sounds a bit complex - but the big question is "why" ? If you do multi-process, you can just go simple and say that one process runs a single app - thus resolving most security issues ( no longer need a sandbox ), you can set use limits, etc. Upgrading the app will no longer leak resources, you can have the old version running for a while, in parallel with the new one ( with some tricks in the lb - for example use session to direct to the right version ). Having multi-process and combining multiple apps in a single process seems pointless. The other nice thing would be to fire up the process on demand, and kill them if not used - and maybe start new processes if needed. > > Third goal is to allow graceful restarts which would > allow to reconfigure the entire VM or redeploy the > application without down time. > Yes, but 1 app ( and one version ) per process would make it easier. > Those kind of things is done nowadays by using some sort > of clustering where each node actually behaves like one > of Httpd's child processes. > > First thing I'm going to do is the thorough analysis > of what actually happens under the hood during different > engine life stages and see what resources might require > the synchronization or cross-process sharing and > how to do that. > IMHO if you use such a model, it may be better to change the directory structure - and have all the files ever created by an webapp ( including logs, work dir, etc ) under a single tree. Than you can chroot to it, versioning may also be easier. > > I know it might sound very complex, but it's actually > doing what Tomcat is suppose to do (be a servlet engine), > so perhaps Tomcat Light would fit in that story. I don't think it's that hard - starting tomcat7 'standalone', with minimal config and a different dir structure is easy. The trick will be the frontend - load balancer plus logic to start the right processes. Costin > > > > Regards > -- > ^TM > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
