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
|