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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
