Yefym Dmukh wrote:
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.
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.
For 10 nodes the replication cost would be to high even for a smaller
session class, but you can at least use domain clustering model,
and slice that to 5x2 nodes.
BTW, what about the bidirectional jvm-lb connection and the stop-the-world
GC managed by lb, as keep it simple approach ?
This won't help much. The sticky session requests must be served
by the same node (group of nodes if using domain clustering),
and your requests will still be delayed by the JVM instance GC cycle
(It has to happen sometime, and you cannot depend on request
void intervals)
Of course since LB updates it's statistics after the request, and if
the request is delayed, right now we cannot react proactive on queued
requests, so new request can be delayed as well instead passed to the
node that is not within the GC cycle (during the GC cycle itself).
To solve the later problem we don't need the two-way communication,
because this can be solved by the LB by taking into account the number
of queued request as well, but we need it for a different things.
However all this is major technology upgrade and it's part of JK3 roadmap,
because it requires both protocol and substantial code change.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
