PROPOSAL: mod_jk2: Group/Instance

[co...@covalent.net]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: PROPOSAL: mod_jk2: Group/Instance

[co...@covalent.net]

On Tue, 30 Apr 2002, Bernd Koecke wrote:

> 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 :).

I think it is in mod_jk, I remember seeing the commit. 

And I think I commited it in jk2 as well ( after some modifications ).

> 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.

Well, there is another use-case with the exact same behavior - Apache2 
with tomcat in JNI mode. All requests without session should be routed to 
the _jni_ channel ( i.e. in-process, minimal overhead ).

It's exacly the same - so be sure I do my best to handle this case :-)

Apache2 acts like a 'natural' load-balancer/fail-over, with the parent
process monitoring for crashes and it starts/stop childs based on 
load.


> 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?

The default is balancing, but you can tune this using weithgs ( and I 
think we use your code for making one instance 'top priority').

Please check the code, take a look and send additional comments/patches.

It's not yet completely done, of course.


Thanks,
Costin 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: PROPOSAL: mod_jk2: Group/Instance

[Bernd Koecke <bk...@schlund.de>]

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

costinm@covalent.net 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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



-- 
Dipl.-Inform. Bernd Koecke
UNIX-Entwicklung
Schlund+Partner AG
Fon: +49-721-91374-0
E-Mail: bk@schlund.de


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>