tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GOMEZ Henri" <hgo...@slib.fr>
Subject RE: PROPOSAL: mod_jk2: Group/Instance
Date Fri, 03 May 2002 21:20:13 GMT
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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message