Hi Costin, some weeks ago I send a patch for mod_jk for an only routing lb_worker. A few days later I sent the docu. Henry Gomez said, that it should be commited. But it I think it isn't in the repository. But its the same with me here, to mutch work for to less time :).
Again an example of my environment: Cluster with 4 nodes, tomcat and apache on every node. One Loadbalancer in front of the cluster which does a simple round robbin. I need sticky sessions but no loadbalancing in the module. If a request without a session comes in, it should be routed to the _local_ tomcat. I think this could be possible with the associated instance of a channel (item 7). Then I have to configure all four nodes for the same group. Because all nodes will serve the same webapps and associate the channel with this group. But for this I need a non balancing group. I don't see if the default behavior of a group is balancing and if this can be switched off. Is this right or do I miss something? Thanks Bernd [EMAIL PROTECTED] wrote: > One of the major goals of mod_jk2 is simpler configuration. > > 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 ). > > 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 > > 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. > 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. > > 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. > > 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. > > 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 ). > > 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. > > Costin > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
