This is not about assuming that Axis2 nodes are going to be load balanced. The clustering/group mgt framework underlying Synapse is based on Axis2. There is no group comm facility available at the Synapse layer. I've designed the Axis2 clustering implementation such that it can run either in application or load balancer modes. In the load balancer mode, it simply informs Synapse about the changes in the application group memebership. So the given axis2.xml file shows how Synapse needs to be configured to be deployed as a clustered load balancer, managing a set of application nodes which belong to the application domain. Of course, we may have .Net nodes in this application domain. However, the group communications protocol at the .Net cluster and that used by Synapse need to be interoperable since the load balancer discovers the application members using the group communication service.
Azeez On Thu, Jun 12, 2008 at 5:44 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote: > I guess what I mean is - suppose its not Axis2 that is being load > balanced. Can we make a plug-point/API where Synapse gets information > on the status of the cluster. Then we could also load-balance a .NET > cluster by writing a plug-in that provides that information. > > So rather than configuring this in the axis2.xml, we could have a > parameter in the Synapse config: > > <endpoint> > <intelligentLoadbalance > helper="org.apache.axis2.cluster.LoadBalanceInformationHelper"/> > </endpoint> > > or > > <endpoint> > <intelligentLoadbalance > helper="org.apache.synapse.extensions.dotNetLoadBalanceInformationHelper"/> > </endpoint> > > Paul > On Thu, Jun 12, 2008 at 4:52 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 > > > > -- > 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
