>You have oxymoron here. With session stickiness you are willingly >tear down the load balancer correctness because you don't wish/can >have session replication. >Even with the smartest LB and even with the two way communication >it's only possible to make that working in non session stickyness >topology. In other case you would loose sessions on each GC cycle. >However like Rainer said the solution is to choose >the appropriate GC strategy for web based application.
Generally you are right, but the ideal world is not the reality: we use apache my faces implementation of jsf where the core session class size is about 500KB, the compression of state kills CPU, the size kills session replication/failover approach. So we have is what we have aqnd we are trying to get the best out of it. BTW, what about the bidirectional jvm-lb connection and the stop-the-world GC managed by lb, as keep it simple approach ? Mladen Turk <[EMAIL PROTECTED]> 05.07.2007 13:19 Please respond to "Tomcat Developers List" <dev@tomcat.apache.org> To Tomcat Developers List <dev@tomcat.apache.org> cc Subject Re: Feature request /Discussion: JK loadbalancer improvements for high load Yefym Dmukh wrote: > > Actually the following was happening: the LB sends requests and gets the > session sticky, continuously sending the upcoming requests to the same > cluster node. At the certain period of time the JVM started the major > garbage collection (full gc) and spent, mentioned above, 20 seconds. At > the same time jk continued to send new requests and the sticky to node > requests that led us to the situation where the one node broke the SLA on > response times. > You have oxymoron here. With session stickiness you are willingly tear down the load balancer correctness because you don't wish/can have session replication. Even with the smartest LB and even with the two way communication it's only possible to make that working in non session stickyness topology. In other case you would loose sessions on each GC cycle. However like Rainer said the solution is to choose the appropriate GC strategy for web based application. Regards, Mladen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
