This can be done. I will send a patch once I implement this. Thanks Azeez
On Thu, Jun 12, 2008 at 11:18 AM, Ruwan Linton <[EMAIL PROTECTED]> wrote: > 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" -- Thanks Afkham Azeez http://afkham.org http://www.wso2.org GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
