From dev-return-12625-apmail-synapse-dev-archive=synapse.apache.org@synapse.apache.org Tue Sep 07 08:46:44 2010 Return-Path: Delivered-To: apmail-synapse-dev-archive@www.apache.org Received: (qmail 81591 invoked from network); 7 Sep 2010 08:46:43 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 7 Sep 2010 08:46:43 -0000 Received: (qmail 26874 invoked by uid 500); 7 Sep 2010 08:46:43 -0000 Delivered-To: apmail-synapse-dev-archive@synapse.apache.org Received: (qmail 26685 invoked by uid 500); 7 Sep 2010 08:46:40 -0000 Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@synapse.apache.org Delivered-To: mailing list dev@synapse.apache.org Received: (qmail 26678 invoked by uid 99); 7 Sep 2010 08:46:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Sep 2010 08:46:39 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sameera.madushan@gmail.com designates 209.85.212.42 as permitted sender) Received: from [209.85.212.42] (HELO mail-vw0-f42.google.com) (209.85.212.42) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Sep 2010 08:46:35 +0000 Received: by vws18 with SMTP id 18so4668782vws.15 for ; Tue, 07 Sep 2010 01:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=WRYqmUVeoktJsYS/HdgBMP7sTo6qn9b+JjCHX/1PoVA=; b=HlsqHvQ533bMUkoh9l9dn89aygpijC5mTf5y/NY5u7b9HAYQRPKqMLeQ+2XK1FDbpl /pxB8nFA8IseepwNL1X/SkKWxrXQ+PoAj+FG279goik9oc0u++ULxP/jgIMAIZHXrkw0 U6lSRmxbdWIXgz811pQ1+YsLE5Hp/vi5V/auA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=aZ3mTM6IEOcR8ZK5tPMj92CWhypGO8A/7hTIhMYSpEQGoM6QP2K8N3dDYsQRlUKXaM dGGDU3JYRWC2VLE9gSso9aUXpAzGJwJfRVIyi6yalIik0pUx6DKIlu4AdLJGQh/asBvr GSxYwpg3InjQcsTj0pjqtInfoDG5yNqYzChNw= MIME-Version: 1.0 Received: by 10.220.122.66 with SMTP id k2mr437987vcr.18.1283849174244; Tue, 07 Sep 2010 01:46:14 -0700 (PDT) Received: by 10.220.189.205 with HTTP; Tue, 7 Sep 2010 01:46:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Sep 2010 14:16:14 +0530 Message-ID: Subject: Re: Improving the DynamicLBEndpoint to support Session Affinity based Load Balancing. From: Sameera Jayasoma To: dev@synapse.apache.org Content-Type: multipart/alternative; boundary=0050450158c3f9dfbc048fa76d42 --0050450158c3f9dfbc048fa76d42 Content-Type: text/plain; charset=ISO-8859-1 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 < > 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? Thanks Sameera > >> 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. (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. http://wso2.org/ blog: http://tech.jayasoma.org --0050450158c3f9dfbc048fa76d42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ruwan,

Thanks for the response. Please see my comments below.
=
On Mon, Sep 6, 2010 at 11:56 PM, Ruwan Linto= n <ruwan.linton@gmail.com> wrote:
Hi Sameera,
First of all sorry for the delay in responding, please find my comments i= n-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 DynamicLoadBalancingEndpo= int selects a member node(Member) in a round robin fashion and creates an A= ddressEndpoint to send the request. Likewise for each and every request an = AddressEndpoint is created and the EPR is calculated using the host name an= d 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 balancin= g endpoint. Hence all utility classes(Dispatchers, SALSession and SessionIn= formation) are written to work in a static environment where all the endpoi= nts are available during the initialization time of the LBEndpoint. And the= se utility classes are written to work with Endponts. I.e they keep mapping= s between sessions and endpoints. But for Session affinity based DynamicLB,= =A0 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 m= ember 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.
=A0

I got your point. We can work on chang= ing 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 a= nother solution. In fact it is a quick and dirty one.=A0 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?

Thanks
Sameera

RoundRobin algorithm for selecting the next member/endpoint for session= affinity based load balancing is not sufficient. In the worst case, we mig= ht hit a situation where all the sessions are attached to a single member/e= ndpoint. IMV, we need an algorithm which considers the parameters such as a= ttached 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 th= e configuration of the endpoint.

Thanks,
Ruwan
=A0

Your thoughts are welcome.

Thanks
Sameera
--
Sameera Jayasoma
Technical Lead & Product Manager, WSO2 Carbon

WSO2, In= c. (http://wso2.com)
email: sameera@wso2.c= om
blog: htt= p://tech.jayasoma.org

Lean . Enterprise . Middleware



--
Ruwan Linton
S= oftware 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@w= so2.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
Tec= hnical Lead
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/

blog: = http://tech.jayasoma= .org
--0050450158c3f9dfbc048fa76d42--