Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
In-Reply-To: <468CD3C3.1060000@apache.org>
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Subject: Re: Feature request /Discussion: JK loadbalancer improvements for
 high load
MIME-Version: 1.0
Message-ID: <OF9D6876CD.0349A9B4-ONC125730F.003EAFAB-C125730F.003FB57C@icw.de>
From: Yefym Dmukh <Yefym.Dmukh@icw-global.com>
Date: Thu, 5 Jul 2007 13:32:38 +0200
Content-Type: multipart/alternative;
 boundary="=_alternative 003FB57BC125730F_="

--=_alternative 003FB57BC125730F_=
Content-Type: text/plain; charset="US-ASCII"

>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 <mturk@apache.org> 
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


--=_alternative 003FB57BC125730F_=--