tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: Mod_Jk2 - Default Worker
Date Mon, 09 Feb 2004 02:06:10 GMT
NormW wrote:
> Good morning Costin.
> Thanks for the time given to replying.
> I agree with the ideas you have given, of decoupling URI's from workers
> explicitly tied to a communications protocol, but in reality this
> connectivity is supported and actually gives the minimum workable
> configuration. But given that a default architecture is but a 'guess', I see
> the programming to be 'cleaner' without such defaults and rather provide a
> 'default' configuration file that would achieve the same end. The present
> situation hides the basic building blocks of Mod_Jk2 and leads to the
> majority of questions in regard to how to reconfigure the module. Remove the
> ability of 'workers' to directly accept requests and force all URI's through
> an lb type, and the current default approach would be entirely appropriate.

Yes, it would be nice to make a clean cut and use a different interface 
for "protocol" workers ( channels ) and lb and similar request processors.

Lb is not only "load balancing" - it also implements fail over and can 
be used to accept registration for tomcat instances - i.e. a sort of 
zero config, with tomcat instance(s) announcing themself to lb.

>>>name    uri    group   context
>>> *         null   null       null
>>> */        /       lb:lb      /
> 
> Given the present arrangement, I can understand (if not support) the lb:lb
> uri entry above but the one assigned to a 'null' group with a uri of 'null'
> seems to be a bug.

It is a bug. Even the second can be considered a bug - if no tomcat 
instance is present there is no need for an lb:lb.

However the most common case is to have at least one tomcat, and there 
is no real benefit in supporting an arbitrary name for the worker ( 
lb:lb ) or in mapping the request directly to the protocol. I think the 
goal should be to have the protocol ( ajp worker ) register itself 
automatically with the lb:lb.

In the advanced case, of multiple pools or instances handling different
webapps - there is no harm in having a default ( lb:lb ) and explicitely
mapping the webapps that don't fall into the default with lb:GROUP 
names. This case can be zero-configured by having each tomcat instance 
self-register with ajp URI and GROUP ( plus the webapps )

IMO getting to this point requires removing some of the (arbitrary ) 
flexibility in naming workers or bypassing the lb.


> 
> As noted, the proposed patch subtracts nothing from the present position,
> while allowing access to the parameter if required.


That's a very common problem - having additional configuration 
flexibility, but without any immediate benefit. It doesn't substract 
anything, but it may prevent future simplifications.



>>I'm ok with any renaming or clarification or defaults - as long as we keep
>>or increase the current separation between "protocols" ( i.e. ajp-like
>>workers ) and "clusters"/"instances" - or however you want to call the
>>lb-like workers.
> 
> That tie-up exists because the worker name was derived from the protocol.
> Ideally the protocol should have been in the channel, leaving the 'worker'
> to handle _a_ request, and lb to decide which worker to get it... assuming
> there is more than one Tomcat to receive it. However, it still doesn't make
> much sense to have a balancer capability in front of a single worker.

I think we discussed this a lot in the past - and my proposal was to 
stop using the term "worker" :-)  The request is mapped by a mapper that 
    decides if it's a servlet and to which group it should go ( with 
lb:lb as a clear default ), then the lb decides on a particular channel.

mod_jk1 does this using a single concept - worker, in jk2 I think a lot 
have changed to split things into mapper, group and channel, with some 
attempts to provide defaults for the common case.


Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message