Hi Ruwan,

Thanks for the response. Please see my comments below.

On Mon, Sep 6, 2010 at 11:56 PM, Ruwan Linton <ruwan.linton@gmail.com> wrote:
Hi Sameera,

First of all sorry for the delay in responding, please find my comments in-line;

On Thu, Sep 2, 2010 at 2:32 PM, Sameera Jayasoma <sameera.madushan@gmail.com> wrote:
Hi Folks,

I am working on the $Subject.

The existing DynamicLoadBalancingEndpoint selects a member node(Member) in a round robin fashion and creates an AddressEndpoint to send the request. Likewise for each and every request an AddressEndpoint is created and the EPR is calculated using the host name and the port of the member. But when it comes to supporting session affinity, we need keep a mapping of sessions with Members.

In Synapse we have a Session affinity based static load balancing endpoint. Hence all utility classes(Dispatchers, SALSession and SessionInformation) are written to work in a static environment where all the endpoints are available during the initialization time of the LBEndpoint. And these utility classes are written to work with Endponts. I.e they keep mappings between sessions and endpoints. But for Session affinity based DynamicLB,  we need to hold information about members and attached sessions.

We could abstract out those utility classes and bring in the concept of a member, so what I am saying is we change the API to work with members, and the member nodes and endpoints are 2 different member implementations of the type member that works with the above utility classes, that way we could get rid of the endpoint binding in these utility classes.

I got your point. We can work on changing the API written to deal with Session affinity LB. The only concern I am having is this. Member node can contain many endpoints

But I have another solution. In fact it is a quick and dirty one.  If you look at the implementation of the RoundRobin algorithm, you will see that it maintains two different instance variables for Endpoints and Members. This algorithm either selects Endpoints or Member, but not both. We can change the above mentioned API support both Endpoints and Members. WDYT?


RoundRobin algorithm for selecting the next member/endpoint for session affinity based load balancing is not sufficient. In the worst case, we might hit a situation where all the sessions are attached to a single member/endpoint. IMV, we need an algorithm which considers the parameters such as attached sessions to a member or an endpoint, in flight requests, etc.

Agreed, so it is just a matter of implementing what ever you want as a LBalgorithm and specifying that as the policy in the configuration of the endpoint.


Your thoughts are welcome.


Sameera Jayasoma
Technical Lead & Product Manager, WSO2 Carbon

WSO2, Inc. (http://wso2.com)
email: sameera@wso2.com
blog: http://tech.jayasoma.org

Lean . Enterprise . Middleware

Ruwan Linton
Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb

WSO2 Inc.; http://wso2.org

Lean . Enterprise . Middleware

phone: +1 408 754 7388 ext 51789
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://blog.ruwan.org
linkedin: http://www.linkedin.com/in/ruwanlinton
google: http://www.google.com/profiles/ruwan.linton
tweet: http://twitter.com/ruwanlinton

Sameera Jayasoma
Technical Lead
WSO2 Inc.
Oxygenating the Web Service Platform.

blog: http://tech.jayasoma.org