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: <402B4B90.2050202@fujitsu-siemens.com>
Date: Thu, 12 Feb 2004 10:46:56 +0100
From: jean-frederic clere <jfrederic.clere@fujitsu-siemens.com>
Reply-To: jfrederic.clere@fujitsu-siemens.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20040130
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> <402B47E4.5030500@apache.org>
In-Reply-To: <402B47E4.5030500@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Henri Gomez wrote:
> 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.

POST data could be very big.

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

May be better to send an empty POST data packet.

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


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