Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <402B47E4.5030500@apache.org>
Date: Thu, 12 Feb 2004 10:31:16 +0100
From: Henri Gomez <hgomez@apache.org>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: Mod_Jk2 - Default Worker
References: <015101c3ec47$3557b740$b441ca0a@nwinc.org.au>
 <bvvgm1$nd6$1@sea.gmane.org> <012c01c3edda$80f81020$b441ca0a@nwinc.org.au>
 <c06puk$o4k$1@sea.gmane.org> <08b401c3f109$ff562060$b441ca0a@nwinc.org.au>
 <c0erfm$ng8$1@sea.gmane.org>
In-Reply-To: <c0erfm$ng8$1@sea.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Costin Manolache wrote:
> 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 :-)

We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so new 
features should wait for 2.0.5.

BTW, I add some fix in jk 1.2.x to make POST recovery in LB mode and I 
agree that the LB shouldn't be seen as a worker.

What I like to see to make easier the LoadBalancing/Failover in jk2 :

- in service, grab request HEADERS and POST datas and store BOTH
   in the service land.

- forward the HEADERS/POST datas to the first worker, and
   if transmission failed or no replies came after XXX seconds,
   forward the HEADERS/POST to another worker and so on.


When I see how ajp13 works in jk (don't look at jk2 for now),
the mix of buffers is a nightmare, since ajp13 mix send part of
datas from webserver to tomcat, and reception of datas from tomcat to
webserver.

What I'd like to see is a more simpler communication system, where
webserver will send ONE packet containing HEADERS and another with
POST datas (if needed).

>>> 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 :-)
> 
> Costin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 
> 


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