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]
