Jim Jagielski wrote:
I'm trying to figure out which impl of the the LB cluster set makes the most sense and would appreciate the feedback.Basically, I see 2 different methods: 1. Members in all cluster sets which have the same or lower set numbers are checked 2. Only members is a specific set number are checked. If none are usable, skip to the next cluster set. In other words, lets assume members a, b and c are in set 0 and d, e and f are in set 1 and g, h and i are in set 2. We check a, b and c and they are not usable, so we now start checking set 1. Should we re-check the members in set 0 (maybe they are usable now) or just check members of set 1 (logically, the question is whether we doing a <= set# or == set#). I have both methods coded and am flip-flopping on which makes the most sense. I'm leaning towards #1 (<=set#). Comments?
Something I planned to implement: <Proxy balancer://clusterName#groupRoute1> BalancerMember .. 1.1 BalancerMember .. 1.2 </Proxy> <Proxy balancer://clusterName#groupRoute2> BalancerMember .. 2.1 BalancerMember .. 2.2 </Proxy> <Proxy balancer://clusterName#groupRoute3> BalancerMember .. 3.1 BalancerMember .. 3.2 </Proxy> In case you have session stickyness, where jvmRoute is equal for all group members and all members from groupRoute1 fails, the groupRoute1 will always be favored depending on the retry timeout. Now if all members from groupRoute2 fails, the next election will still first try to check the corresponding sticky route members (if they are ready for retry). So, if you always first try the corresponding members of the session route balancer, you will always favor them over the others. Think this is close to your #1. Next step is to add the shared memory slot for balancer, so it can be dynamically maintained. -- Mladen.
