>I think the current solution of generating configs on tomcat startup, >or having tomcat send it's config to apache is wrong.
when tomcats and httpd servers run on differents machines you need to have a form of link between them, and that's why I proposed autoconf to be added to ajp13 (I don't tell ajp14 to avoid confusion). I agree we have a sort of chicken and eggs problems here since httpd servers need to know which tomcat are available to try to connect to them to get the configuration. Ideally we need a broadcast solution for such purpose. httpd server should have a thread (or fork in AP 1.3) to listen to incoming broadcast notification and determine if there is a new tomcat in (or out) and contact newcomer to get its config informations. In case of tomcat caming out, it should remove references to the old tomcat. - In java land there is a solution, javagroups (http://sourceforge.net/projects/javagroups/) which sadly still use a LGPL license which prevent to have it include in ASF project. If ever javagroups decide to switch to a BSD license or better join jakarta, it will be really great and in that case we could use httpd + jni + javagroups to talk and configure the groups of distants tomcats - In native/java land, there is still spread (http://www.spread.org) which have a license compatible with ASF. >Finally, the shmem system that is ( will be ) used for >autoconfiguration >of workers ( i.e. when a tomcat starts up it can add itself >automatically, >without admin intervention ) can be used by the deploy/admin tool to >reconfigure uri mappings ( with the common mapper, the native mapper >still requires a soft restart - but that can be automated as well ). > >Implementation-wise - this is not difficult, and can be done pretty >fast if Glenn and few other people step in. > >I believe that's going to be very close to 'minimal' pain for the >regular user while preserving the ability to fine tune everything. > >NOTE: jk2 will use a different model for the lb, see next mail. You're speaking of channel, I'd like the idea, since it's very similar to the channel/group concept of javagroup/spread. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
