Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic.
> 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. * With a release of mod_jk2 imminent, someone might look at this perhaps? > 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. That mapping only exists now because it is implemented by the worker. The worker is the logical recipient if the functionality offered by the lb worker was not required. (There is enough for a worker to manage, even without the protocol, to justify its existence as an object.). All that is missing from the scenario is the protocol to be a part of the channel or perhaps an intermediate layer. > 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 ) Given the diversity of structures that mod_jk2 can implement, having a default configuration only caters for a portion of them. Catering for none forces 'exposure' of the few building blocks that mod_jk2 actually has available, and would help to remove a lot of the mod_jk/jk2 mystique. > IMO getting to this point requires removing some of the (arbitrary ) > flexibility in naming workers or bypassing the lb. >From an 'objects' perspective, it is inconsistent with current practice to 'parse' object names (CN in ldap parlence) for properties of the object, when those properties have unique identifiers such as port and host. Hence I support arbitrary naming.... ;-( > > > > > 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. Point taken. Equally, it's absence today shouldn't automatically mitigated against its existence tomorrow. If 'mod_jk3' should evolve perhaps.... > > > >>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 Thanks again for the time, feedback and insight. Norm > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
