tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Mod_Jk2 - Default Worker
Date Thu, 12 Feb 2004 03:20:43 GMT
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.

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

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

In any case - it's Henri and the other people actively involved in this 
release you need to convince :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message