Not too late for comments ?
>This proposal will cover the 'workers'. > >1. The 'worker' name is deprecated. It refers to too many >things in mod_jk, and causes too much confusion ( i.e. it >is a 'handler', coresponds to a jvmRoute, a protocol, a >channel ). +1, worker term should be related to a processing job/thread not communication (a multiplexing worker could handle multiple connections) >2. We'll use the term 'channel' to define the connections >between jk and tomcat. Each channel will follow a standard >naming syntax: > channel.socket:HOST:PORT > channel.unix:/PATH > channel.jni:jni +1 >Altenatively, the local part can be used as a shortcut. >Each channel will use Ajp13 protocol by default ( or whatever >is specific to the transport, or overriden ). > >3. We'll use the term 'instance' ( XXX or a better name >if you can sugest one ) to refer to a single tomcat VM. >That's what will be used in the jvmRoute. A tomcat instance >can be reached by multiple channels. socket/unix/jni - ok >By default, each instance will have one socket channel and >will be named by the local part ( i.e. HOST:port ). That's the >name that'll identify the VM. Only one socket channel listening but with multiple active sockets isn't it ? >4. We'll use the term 'group' to reffer to a set of tomcat >'instances' that share a number of applications. The default >group will be called 'lb'. One 'instance' can be part of >one or many groups. Group will group VM (which could be in the same or differents machines) >5. Each URI will be associated with a 'group'. In what used to >be: > JkMount /examples ajp13 >the 'group' will replace ajp13. >As I said, the default group is called 'lb' and includes all >tomcat instances that are defined. >For each application that is installed on all instances, the 'lb' >group must be used. >If you have a sophisticated setup - and an app is installed >only on some instances, you can use names like "lb_examples", >and explicitely define what tomcat instances belong to the group. ok >6. The webapps will be defined by a hierarchy of directories >( host/webapp_name ) ( see previous mail ). Each webapp >is obviously mapped consistently to one group, which will be >defined inside the WEB-INF/jk2/map.properties. >7. Each channel will have an associated 'instance' ( it can't > go to 2 tomcats ) and groups. The lb configuration is >done automatically based on those attributes. The mappings >are done automatically based on the hierarchy. If no map.properties >is found, the whole webapp will be forwarded to the default >group ( the common case ). ok (specific map.properties will be usefull when you want your php/gif/html handled by the primary webserver) >I believe this model covers all current use cases. Please, please, >send feedback and let me know if you can help ( implementation, >documentation, testing ), but feedback is the first step. You got my first comment here. The webserver(s) will receive notification of map.properties, the planned autoconf features of ajp14. map.properties will have to be transmitted via all channel to the corresponding web-server(s). The good point is that this grouping will help abstracting load-balancing from underneath protocol/channel. I continue the reading of the thread -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
