synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sameera Jayasoma <>
Subject Re: Improving the DynamicLBEndpoint to support Session Affinity based Load Balancing.
Date Tue, 07 Sep 2010 08:46:14 GMT
Hi Ruwan,

Thanks for the response. Please see my comments below.

On Mon, Sep 6, 2010 at 11:56 PM, Ruwan Linton <>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 <
>> 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.
> Thanks,
> Ruwan
>> Your thoughts are welcome.
>> Thanks
>> Sameera
>> --
>> Sameera Jayasoma
>> Technical Lead & Product Manager, WSO2 Carbon
>> WSO2, Inc. (
>> email:
>> blog:
>> Lean . Enterprise . Middleware
> --
> Ruwan Linton
> Software Architect & Product Manager, WSO2 ESB;
> WSO2 Inc.;
> Lean . Enterprise . Middleware
> phone: +1 408 754 7388 ext 51789
> email:; cell: +94 77 341 3097
> blog:
> linkedin:
> google:
> tweet:

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


View raw message