I didn't say anything about "just simple round robin" the algorithm for distribution can be entirely separate from the "stickiness" as they are two separate things. The distribution algorithm, (round ron, load, random, etc) is separate and should not be confused. Stickyness means that if I have been to one server, I should go to that server again and again until that server fails or meets another criteria to not receive requests.
And this "another criteria" is a _very_ important use case ( and one of the reasons I am insisting on having some form of dynamic configuration/jmx/whatever ).
Many large servers ( banks, etc ) would not want to lose client sessions when they upgrade a worker in the pool - so they need to be able to tell that a particular instance should not be included in the "round robin" for new sessions, but only get the requests from previous sessions.
They also need to be able to add more workers, or remove some workers from the pool.
I know, the jk implementation is very ugly - but IMO this use case is quite important and it shouldn't be lost.
Costin
Filip
----- Original Message ----- From: "Mladen Turk" <[EMAIL PROTECTED]> To: "'Tomcat Developers List'" <[EMAIL PROTECTED]> Sent: Wednesday, July 21, 2004 11:30 AM Subject: RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
Filip Hanik wrote:
The current jvmRoute addition to JSESSIONID is not really needed, since it doesn't add that much of a benefit over the two options above. So right then and there, there is one less thing to configure.
Ok, If we'll make a lb for a mod_proxy, then at least it will need a balance load factor, not just sticky sessions and simple round robin. Also the JSESSIONID then does not to be harcoded, but rather configurable.
MT.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
