Azeez, This seems cool, and this will be a good addition to synapse.
I remember there was a user request for this kind of a load balance scenario some time back. One small suggestion; it will be good to have the same implemented as non intelligent LB :-) I mean you can specify the server host names (ip address and ports) in the load balancer configuration (they will not be automatically discovered) and synapse load balances any request comes to the it on round robin to the specified servers. This is same as what you have done but just without the intelligence of the servers (you have to specify them). A use case for this is sometime one may want to direct messages only to a set of servers but not to all in the cluster, or when there is no cluster (just a few servers which provides the same service). Thanks, Ruwan On Thu, Jun 12, 2008 at 11:02 AM, Afkham Azeez <[EMAIL PROTECTED]> wrote: > I also need to mention that the membership scheme, load balancer > group and application group can be specified in the cluster configuration > section of the axis2.xml file. The relevant section in the axis2.xml is > hsown below: > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > <!-- > The membership scheme used in this setup. The only values > supported at the moment are > "multicast" and "wka" > > 1. multicast - membership is automatically discovered using > multicasting > 2. wka - Well-Known Address based multicasting. Membership is > discovered with the help > of one or more nodes running at a Well-Known Address. > New members joining a > cluster will first connect to a well-known node, > register with the well-known node > and get the membership list from it. When new members > join, one of the well-known > nodes will notify the others in the group. When a > member leaves the cluster or > is deemed to have left the cluster, it will be detected > by the Group Membership > Service (GMS) using a TCP ping mechanism. > --> > <parameter name="membershipScheme">multicast</parameter> > > <!-- > The clustering domain/group. Nodes in the same group will belong > to the same multicast > domain. There will not be interference between nodes in different > groups. > --> > <parameter name="domain">apache.axis2.domain</parameter> > > <!-- > Indicates the mode in which this member is running. Valid values > are "application" and > "loadBalance" > > application - This member hosts end user applications > loadBalance - This member is a part of the load balancer cluster > --> > <parameter name="mode">application</parameter> > > <!-- > This is the even handler which will be notified in the case of load > balancing events occurring. > This class has to be an implementation of > org.apache.axis2.clustering.LoadBalanceEventHandler > > This entry is only valid if the "mode" parameter is set to > loadBalance > --> > <parameter name="loadBalanceEventHandler"> > org.apache.synapse.core.axis2.SynapseLoadBalanceEventHandler > </parameter> > > <!-- > This parameter is only valid when the "mode" parameter is set to > application. This indicates > the domain in which the the applications being load balanced are > deployed. > --> > <parameter > name="applicationDomain">apache.axis2.application.domain</parameter> > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > Session affinity and failover will also be provided with this Intelligent > Load Balancer implementation. > > Thanks > Azeez > > > On Thu, Jun 12, 2008 at 9:22 AM, Afkham Azeez <[EMAIL PROTECTED]> wrote: > >> >> >> On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote: >> >>> Azeez >>> >>> First thoughts are this is *very* cool. >>> >>> My second thought is that its a little too "hard coded". It would be >>> nice to allow plugging in different group/cluster discovery >>> mechanisms. >>> >> >> Can you further elaborate on what you meant by the group discovery >> mechanism being hard-coded? The underlying Axis2 based clustering >> implementation now supports dynamic, static & well-known address (hybrid) >> group discovery, this will be automatically available. See >> http://afkham.org/2008/05/group-membership-management-schemes.html. Also, >> the we can plug-in a different implementation based on a different group >> communication framework. >> >> Azeez >> >> >> >>> Paul >>> >>> On Wed, Jun 11, 2008 at 12:47 PM, Afkham Azeez <[EMAIL PROTECTED]> wrote: >>> > Hi Folks, >>> > There are some limitations in the current load balancer. e.g. if we >>> have 2 >>> > identical services in 2 different worker nodes, which are fronted by a >>> > synapse load balancer instance. In such a case, we need to provide 4 >>> > endpoints in the synapse.xml file. As can be seen, this is not a very >>> > scalable solution. Hence, I'm implementing an Intelligent load >>> balancing >>> > mechanism where the application members are discovered at runtime, and >>> the >>> > endpoint do not need to be statically specified in the synapse.xml >>> file. So >>> > the synapse.xml file will simply look like this: >>> > >>> > <definitions xmlns="http://ws.apache.org/ns/synapse";> >>> > <sequence name="main" onError="errorHandler"> >>> > <in> >>> > <send> >>> > <endpoint> >>> > <intelligentLoadbalance/> >>> > </endpoint> >>> > </send> >>> > <drop/> >>> > </in> >>> > <out> >>> > <send/> >>> > </out> >>> > </sequence> >>> > >>> > <sequence name="errorHandler"> >>> > <makefault> >>> > <code value="tns:Receiver" >>> > xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/> >>> > <reason value="COULDN'T SEND THE MESSAGE TO THE SERVER."/> >>> > </makefault> >>> > <header name="To" action="remove"/> >>> > <property name="RESPONSE" value="true"/> >>> > <send/> >>> > </sequence> >>> > </definitions> >>> > >>> > Currently, the application endpoints are calculated by replacing the IP >>> and >>> > port of the incoming request with that of the member to which this >>> request >>> > will be forwarded to. I have only tested with HTTP/S for the moment. >>> More >>> > details about the design can be found here: >>> > http://afkham.org/2008/06/fault-resilient-dynamic-load-balancing.html >>> > >>> > Please provide your valuable feedback on this approach. >>> > >>> > -- >>> > Thanks >>> > Afkham Azeez >>> > >>> > http://afkham.org >>> > http://www.wso2.org >>> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 >>> >>> >>> >>> -- >>> Paul Fremantle >>> Co-Founder and CTO, WSO2 >>> Apache Synapse PMC Chair >>> OASIS WS-RX TC Co-chair >>> >>> blog: http://pzf.fremantle.org >>> [EMAIL PROTECTED] >>> >>> "Oxygenating the Web Service Platform", www.wso2.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> -- >> Thanks >> Afkham Azeez >> >> http://afkham.org >> http://www.wso2.org >> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 >> > > > > -- > Thanks > Afkham Azeez > > http://afkham.org > http://www.wso2.org > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform"
