Good morning Costin. > NormW wrote: > > Good morning Costin. > > Apologies for the silence. I had hoped there might have been a little more > > input from others on this topic. > > Same here :-) > > > > >>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. > > Not sure what you mean - the "worker" name is very overloaded, there are > many ways to interpret. * Apologies for the mixup.... I knew what I meant. I meant 'worker' in a functional sense as an object/entity that accepts a URI request from Apache and who's sole job is to do all the management processes required to deliver that URI to a Tomcat and back to the client, except actually getting it there. If this object is functionally tweaked for this role it more than adequately meets a large number of user requirements. It is only when features like fail-over, clustering and load-balancing are added to the overall requirement, is an entity with the current 'skills' of an lb-type 'worker' required to decide which 'worker/object' gets the task of processing the request. One doesn't have to stand back very far to discover that is almost what exists now.
> My point was that the mapping is done between a URI and a tomcat ( > either a standalone instance or a group ). This is represented by "lb" - > which should be the only target for the mapping. > > The lb will then use a channel ( ajp object ) to connect to the tomcat. > The role of "lb" is to implement the forwarding of the request via the > "ajp" object, with load balancing or failover ( if multiple channel/ajp > objects exist ). > > The fact that both the channel ( ajp ) and the lb are implementing the > "worker" interface is IMO confusing. I think it's better to have an "lb" > that can dynamically be configured with more channels, does retry, > balancing and failover - as a separate entity- separated from the > channel ( that just forwards a request ). * This dual interface to a single logical task is 'normal' in a lot of things, for example, a one man business and an enterprise employing a number of similarly skilled workers but fronted by a manager who decides which worker gets the job. One should be able to scale the enterprise for the overall task at hand rather than have a manager in front of a single person. (Sounds like a government department.) > > > > >>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.... ;-( > > CN ( and distinguished names in JNDI as well as jmx object names ) is > the source for the object names in jk2. > > I know it's a religious issue if the name should mean something or not - > and probably that's a reason we'll have to keep supporting the > arbitrary names. > > IMO we should deprecate the arbitrary names and only support JMX-like > object names, with using the properties to extract information like > host, etc. Acknowledge being unfamiliar with the JMX standard, but if it means not parsing object names for properties then I'm a supporter. > > In any case - it's Henri and the other people actively involved in this > release you need to convince :-) * I don't have 'barrow' to push much beyond wanting to make mod_jk2 function in what I perceive is a logical way and have it's modular design become visible enough to remove a lot of the questions I see on user groups about configuring it. If I convince anyone to re-evaluate past decisions it is a by-product. > > Costin > 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]
