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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- 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]
