> > 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 is this even possibe? I am not aware of any group communication toolkit that has multiple language support. Even if one exists, then both the .NET cluster and axis2 has to implement it. The probability of that is very very low. However a more high level group communication protocol that uses SOAP may do the trick. It could use something like WS-Eventing to broadcast a health status every x time interval. The message will include current CPU/Memory and/or other system information. This does not assume any Axis2 group communication support and Synapse will have full control of this. Since this works at the SOAP layer this can be used to manage a heterogenous cluster. I am not familliar with WSDM etc.. but worth looking into as they might already have provisions for this. Just a wild idea that crossed my mind. -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ > > 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 >
