You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Afkham Azeez <af...@gmail.com> on 2008/06/11 13:47:25 UTC
Intelligent Synapse Load Balancer
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
Re: Intelligent Synapse Load Balancer
Posted by Rajith Attapattu <ra...@gmail.com>.
On Sat, Jun 14, 2008 at 1:49 AM, Afkham Azeez <af...@gmail.com> wrote:
> You should be able to use a GCF such as Spread to do this across different
> technologies/languages. Anyway, implementing a membership service which can
> work with say Tribes, in .Net or any other language is trivial since that
> only needs to interpret the membership management TCP & multicast messages
> that are received.
>
I don't agree that this is a trivial exercise. Its almost equivalent to
implementing tribes in .NET or whatever the language.
>From what your are proposing it seems that the ability to be load balanced
by Synapse will be conditional on having the same group communication
mechanism as Axis2. Isn't this a limitation ?
The goal should be to do something with minimum work.
Azeez as Paul suggested can we not have some sort of an intelligent LB that
can manage heterogeneous clusters with different group communication
mechanisms?
Each cluster could broadcast it's cluster info via a plugging which bridges
this info into a common format that the Synapse LB understands.
This provides the Synapse LB with a consistent view of the entire
heterogenous cluster. Based on that info then the intelligent LB can make
its decesisions.
This allows each cluster to be managed by Synapse while stilling having
their own group membership.
Regards,
Rajith
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
You should be able to use a GCF such as Spread to do this across different
technologies/languages. Anyway, implementing a membership service which can
work with say Tribes, in .Net or any other language is trivial since that
only needs to interpret the membership management TCP & multicast messages
that are received.
Azeez
On Fri, Jun 13, 2008 at 8:40 PM, Rajith Attapattu <ra...@gmail.com>
wrote:
> 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 <pz...@gmail.com> 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 <af...@gmail.com> wrote:
>>> >
>>> >
>>> > On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com>
>>> 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 <af...@gmail.com>
>>> 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
>>> >> paul@wso2.com
>>> >>
>>> >> "Oxygenating the Web Service Platform", www.wso2.com
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > 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
>>> paul@wso2.com
>>>
>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>>
>>
>>
>> --
>> 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
Re: Intelligent Synapse Load Balancer
Posted by Rajith Attapattu <ra...@gmail.com>.
>
> 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 <pz...@gmail.com> 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 <af...@gmail.com> wrote:
>> >
>> >
>> > On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com>
>> 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 <af...@gmail.com>
>> 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
>> >> paul@wso2.com
>> >>
>> >> "Oxygenating the Web Service Platform", www.wso2.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > 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
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
>
> --
> Thanks
> Afkham Azeez
>
> http://afkham.org
> http://www.wso2.org
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
Hi Folks,
I have created a patch[1] against the Synapse trunk. Please review it and
send in your comments.
Thanks
Azeez
1. https://issues.apache.org/jira/browse/SYNAPSE-360
On Sun, Jun 15, 2008 at 7:15 AM, Ruwan Linton <ru...@gmail.com>
wrote:
> Azeez,
>
> Thanks for the great explanation and I think this is very cool.
>
> Looking forward to your patch which implements this. When you are adding
> the session affinity please go through Eric's email to the list which will
> give you a good understanding on existing session bind mechanisms as well as
> what we can do more.
>
> Thanks,
> Ruwan
>
>
> On Sat, Jun 14, 2008 at 11:52 PM, Afkham Azeez <af...@gmail.com> wrote:
>
>> Here you go:
>>
>> Consider,
>> *<dynamicLoadbalance failover="true"
>> algorithm="roundrobin2">
>> <membershipHandler
>>
>> class="org.apache.synapse.core.axis2.Axis2LoadBalanceMembershipHandler">
>> <property name="applicationDomain"
>> value="apache.axis2.app.domain"/>
>> </membershipHandler>
>> </dynamicLoadbalance
>>
>> failover=true* indicates that if an error occurs while trying to send to
>> a node, we need to failover to another*
>> algorithm => the LB algorithm
>>
>> *We also need to have configurations for session affinity*.
>>
>> membershipHandler
>> ------------------------------
>> *Since this is about dynamic load balancing, what concerns us is how the
>> members are discovered. This can be plugged in using the implementation of
>> the following interface:
>>
>> public interface LoadBalanceMembershipHandler {
>>
>> /**
>> * Initialize this
>> * @param properties The properties specific to this
>> LoadBalanceMembershipHandler
>> */
>> void init(Properties properties);
>>
>> /**
>> * Get the next application member to whom the message has to be sent
>> to
>> *
>> * @return Next application member to whom the message has to be sent
>> to
>> */
>> ApplicationMember getNextApplicationMember();
>> }
>>
>> The dynamicLoadBalanceEndpoint will call this interface to get the next
>> member to which the message has to be sent to. So, different
>> implementations of this interface may require different properties in order
>> to properly initialize the LoadBalanceMembershipHandler. These are provided
>> using the property entries (yes, you can have multiple of them). When we
>> need to load balance across a domain of Axis2 nodes, we use the underlying
>> Tribes based GCF to our advantage, and provide the "applicationDomain"
>> property. Thereby we need not implement anything related to group membership
>> management. I'm trying to figure out how to properly bridge between the
>> Tribes GCF and Synapse.
>>
>> *
>> *
>> On Sat, Jun 14, 2008 at 9:23 PM, Ruwan Linton <ru...@gmail.com>
>> wrote:
>>
>>> Hi Azeez,
>>>
>>> On Sat, Jun 14, 2008 at 7:36 PM, Afkham Azeez <af...@gmail.com> wrote:
>>>
>>>> Hi Paul/Eric,
>>>>
>>>> I have renamed it to dynamicLoadbalance.
>>>
>>>
>>> This name looks better over the former ;-)
>>>
>>>
>>>>
>>>>
>>>> Eric, I don't think there will be a clash between your improvements and
>>>> mine. I will go through your mail and send you a response.
>>>
>>>
>>> I agree with Azeez, and I think it is yet another session affinity LB
>>> that has to be implemented with the endpoint LB scheme.
>>>
>>>
>>>>
>>>>
>>>> Also as per Paul's feedback and suggestions, I am planning to modify the
>>>> configuration as shown below. With such a configuration, we can load balance
>>>> across multiple groups. Thanks for the feedback and comments. Please keep
>>>> them coming.
>>>
>>>
>>> This seems cool from your words, but just for the clarity can you please
>>> explain the config language a bit more. failover and algorithm attributes
>>> are obvious, but can we have more than one applicationDomain properties and
>>> so on??
>>>
>>> Thanks,
>>> Ruwan
>>>
>>>
>>>>
>>>>
>>>> <sequence name="main" onError="errorHandler">
>>>> <in>
>>>> <send>
>>>> <endpoint>
>>>> *<dynamicLoadbalance failover="true"
>>>> algorithm="roundrobin2">
>>>> <membershipHandler
>>>>
>>>> class="org.apache.synapse.core.axis2.Axis2LoadBalanceMembershipHandler">
>>>> <property name="applicationDomain"
>>>> value="apache.axis2.app.domain"/>
>>>> </membershipHandler>
>>>> </dynamicLoadbalance>*
>>>> </endpoint>
>>>> </send>
>>>> <drop/>
>>>> </in>
>>>> <out>
>>>> <send/>
>>>> </out>
>>>> </sequence>
>>>>
>>>>
>>>> Thanks
>>>> Azeez
>>>>
>>>
>>>
>>> --
>>> Ruwan Linton
>>> http://wso2.org - "Oxygenating the Web Services Platform"
>>> http://ruwansblog.blogspot.com/
>>
>>
>>
>>
>> --
>> 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://wso2.org - "Oxygenating the Web Services Platform"
> http://ruwansblog.blogspot.com/
>
--
Thanks
Afkham Azeez
http://afkham.org
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: Intelligent Synapse Load Balancer
Posted by Ruwan Linton <ru...@gmail.com>.
Azeez,
Thanks for the great explanation and I think this is very cool.
Looking forward to your patch which implements this. When you are adding the
session affinity please go through Eric's email to the list which will give
you a good understanding on existing session bind mechanisms as well as what
we can do more.
Thanks,
Ruwan
On Sat, Jun 14, 2008 at 11:52 PM, Afkham Azeez <af...@gmail.com> wrote:
> Here you go:
>
> Consider,
> *<dynamicLoadbalance failover="true"
> algorithm="roundrobin2">
> <membershipHandler
>
> class="org.apache.synapse.core.axis2.Axis2LoadBalanceMembershipHandler">
> <property name="applicationDomain"
> value="apache.axis2.app.domain"/>
> </membershipHandler>
> </dynamicLoadbalance
>
> failover=true* indicates that if an error occurs while trying to send to a
> node, we need to failover to another*
> algorithm => the LB algorithm
>
> *We also need to have configurations for session affinity*.
>
> membershipHandler
> ------------------------------
> *Since this is about dynamic load balancing, what concerns us is how the
> members are discovered. This can be plugged in using the implementation of
> the following interface:
>
> public interface LoadBalanceMembershipHandler {
>
> /**
> * Initialize this
> * @param properties The properties specific to this
> LoadBalanceMembershipHandler
> */
> void init(Properties properties);
>
> /**
> * Get the next application member to whom the message has to be sent
> to
> *
> * @return Next application member to whom the message has to be sent
> to
> */
> ApplicationMember getNextApplicationMember();
> }
>
> The dynamicLoadBalanceEndpoint will call this interface to get the next
> member to which the message has to be sent to. So, different
> implementations of this interface may require different properties in order
> to properly initialize the LoadBalanceMembershipHandler. These are provided
> using the property entries (yes, you can have multiple of them). When we
> need to load balance across a domain of Axis2 nodes, we use the underlying
> Tribes based GCF to our advantage, and provide the "applicationDomain"
> property. Thereby we need not implement anything related to group membership
> management. I'm trying to figure out how to properly bridge between the
> Tribes GCF and Synapse.
>
> *
> *
> On Sat, Jun 14, 2008 at 9:23 PM, Ruwan Linton <ru...@gmail.com>
> wrote:
>
>> Hi Azeez,
>>
>> On Sat, Jun 14, 2008 at 7:36 PM, Afkham Azeez <af...@gmail.com> wrote:
>>
>>> Hi Paul/Eric,
>>>
>>> I have renamed it to dynamicLoadbalance.
>>
>>
>> This name looks better over the former ;-)
>>
>>
>>>
>>>
>>> Eric, I don't think there will be a clash between your improvements and
>>> mine. I will go through your mail and send you a response.
>>
>>
>> I agree with Azeez, and I think it is yet another session affinity LB that
>> has to be implemented with the endpoint LB scheme.
>>
>>
>>>
>>>
>>> Also as per Paul's feedback and suggestions, I am planning to modify the
>>> configuration as shown below. With such a configuration, we can load balance
>>> across multiple groups. Thanks for the feedback and comments. Please keep
>>> them coming.
>>
>>
>> This seems cool from your words, but just for the clarity can you please
>> explain the config language a bit more. failover and algorithm attributes
>> are obvious, but can we have more than one applicationDomain properties and
>> so on??
>>
>> Thanks,
>> Ruwan
>>
>>
>>>
>>>
>>> <sequence name="main" onError="errorHandler">
>>> <in>
>>> <send>
>>> <endpoint>
>>> *<dynamicLoadbalance failover="true"
>>> algorithm="roundrobin2">
>>> <membershipHandler
>>>
>>> class="org.apache.synapse.core.axis2.Axis2LoadBalanceMembershipHandler">
>>> <property name="applicationDomain"
>>> value="apache.axis2.app.domain"/>
>>> </membershipHandler>
>>> </dynamicLoadbalance>*
>>> </endpoint>
>>> </send>
>>> <drop/>
>>> </in>
>>> <out>
>>> <send/>
>>> </out>
>>> </sequence>
>>>
>>>
>>> Thanks
>>> Azeez
>>>
>>
>>
>> --
>> Ruwan Linton
>> http://wso2.org - "Oxygenating the Web Services Platform"
>> http://ruwansblog.blogspot.com/
>
>
>
>
> --
> 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://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
Here you go:
Consider,
*<dynamicLoadbalance failover="true"
algorithm="roundrobin2">
<membershipHandler
class="org.apache.synapse.core.axis2.Axis2LoadBalanceMembershipHandler">
<property name="applicationDomain"
value="apache.axis2.app.domain"/>
</membershipHandler>
</dynamicLoadbalance
failover=true* indicates that if an error occurs while trying to send to a
node, we need to failover to another*
algorithm => the LB algorithm
*We also need to have configurations for session affinity*.
membershipHandler
------------------------------
*Since this is about dynamic load balancing, what concerns us is how the
members are discovered. This can be plugged in using the implementation of
the following interface:
public interface LoadBalanceMembershipHandler {
/**
* Initialize this
* @param properties The properties specific to this
LoadBalanceMembershipHandler
*/
void init(Properties properties);
/**
* Get the next application member to whom the message has to be sent to
*
* @return Next application member to whom the message has to be sent to
*/
ApplicationMember getNextApplicationMember();
}
The dynamicLoadBalanceEndpoint will call this interface to get the next
member to which the message has to be sent to. So, different
implementations of this interface may require different properties in order
to properly initialize the LoadBalanceMembershipHandler. These are provided
using the property entries (yes, you can have multiple of them). When we
need to load balance across a domain of Axis2 nodes, we use the underlying
Tribes based GCF to our advantage, and provide the "applicationDomain"
property. Thereby we need not implement anything related to group membership
management. I'm trying to figure out how to properly bridge between the
Tribes GCF and Synapse.
*
*
On Sat, Jun 14, 2008 at 9:23 PM, Ruwan Linton <ru...@gmail.com>
wrote:
> Hi Azeez,
>
> On Sat, Jun 14, 2008 at 7:36 PM, Afkham Azeez <af...@gmail.com> wrote:
>
>> Hi Paul/Eric,
>>
>> I have renamed it to dynamicLoadbalance.
>
>
> This name looks better over the former ;-)
>
>
>>
>>
>> Eric, I don't think there will be a clash between your improvements and
>> mine. I will go through your mail and send you a response.
>
>
> I agree with Azeez, and I think it is yet another session affinity LB that
> has to be implemented with the endpoint LB scheme.
>
>
>>
>>
>> Also as per Paul's feedback and suggestions, I am planning to modify the
>> configuration as shown below. With such a configuration, we can load balance
>> across multiple groups. Thanks for the feedback and comments. Please keep
>> them coming.
>
>
> This seems cool from your words, but just for the clarity can you please
> explain the config language a bit more. failover and algorithm attributes
> are obvious, but can we have more than one applicationDomain properties and
> so on??
>
> Thanks,
> Ruwan
>
>
>>
>>
>> <sequence name="main" onError="errorHandler">
>> <in>
>> <send>
>> <endpoint>
>> *<dynamicLoadbalance failover="true"
>> algorithm="roundrobin2">
>> <membershipHandler
>>
>> class="org.apache.synapse.core.axis2.Axis2LoadBalanceMembershipHandler">
>> <property name="applicationDomain"
>> value="apache.axis2.app.domain"/>
>> </membershipHandler>
>> </dynamicLoadbalance>*
>> </endpoint>
>> </send>
>> <drop/>
>> </in>
>> <out>
>> <send/>
>> </out>
>> </sequence>
>>
>>
>> Thanks
>> Azeez
>>
>
>
> --
> Ruwan Linton
> http://wso2.org - "Oxygenating the Web Services Platform"
> http://ruwansblog.blogspot.com/
--
Thanks
Afkham Azeez
http://afkham.org
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: Intelligent Synapse Load Balancer
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Azeez,
On Sat, Jun 14, 2008 at 7:36 PM, Afkham Azeez <af...@gmail.com> wrote:
> Hi Paul/Eric,
>
> I have renamed it to dynamicLoadbalance.
This name looks better over the former ;-)
>
>
> Eric, I don't think there will be a clash between your improvements and
> mine. I will go through your mail and send you a response.
I agree with Azeez, and I think it is yet another session affinity LB that
has to be implemented with the endpoint LB scheme.
>
>
> Also as per Paul's feedback and suggestions, I am planning to modify the
> configuration as shown below. With such a configuration, we can load balance
> across multiple groups. Thanks for the feedback and comments. Please keep
> them coming.
This seems cool from your words, but just for the clarity can you please
explain the config language a bit more. failover and algorithm attributes
are obvious, but can we have more than one applicationDomain properties and
so on??
Thanks,
Ruwan
>
>
> <sequence name="main" onError="errorHandler">
> <in>
> <send>
> <endpoint>
> *<dynamicLoadbalance failover="true"
> algorithm="roundrobin2">
> <membershipHandler
>
> class="org.apache.synapse.core.axis2.Axis2LoadBalanceMembershipHandler">
> <property name="applicationDomain"
> value="apache.axis2.app.domain"/>
> </membershipHandler>
> </dynamicLoadbalance>*
> </endpoint>
> </send>
> <drop/>
> </in>
> <out>
> <send/>
> </out>
> </sequence>
>
>
> Thanks
> Azeez
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
Hi Paul/Eric,
I have renamed it to dynamicLoadbalance.
Eric, I don't think there will be a clash between your improvements and
mine. I will go through your mail and send you a response.
Also as per Paul's feedback and suggestions, I am planning to modify the
configuration as shown below. With such a configuration, we can load balance
across multiple groups. Thanks for the feedback and comments. Please keep
them coming.
<sequence name="main" onError="errorHandler">
<in>
<send>
<endpoint>
*<dynamicLoadbalance failover="true"
algorithm="roundrobin2">
<membershipHandler
class="org.apache.synapse.core.axis2.Axis2LoadBalanceMembershipHandler">
<property name="applicationDomain"
value="apache.axis2.app.domain"/>
</membershipHandler>
</dynamicLoadbalance>*
</endpoint>
</send>
<drop/>
</in>
<out>
<send/>
</out>
</sequence>
Thanks
Azeez
On Fri, Jun 13, 2008 at 4:40 PM, Hubert, Eric <er...@jamba.net> wrote:
> Hi Azeez,
>
> your explanations sounds reasonable to me. I also like the idea of renaming
> your proposal from intelligentLoadbalance to something like
> dynamicLoadbalance as this describes the way in which the actual members of
> the LB group are discovered. The algorithm is responsible for the actual
> distribution of the load (currently only roundRobin in Synapse, but his can
> be improved).
>
> Regarding some improvents to current loadbalancing I wrote a mail to the
> list some time back early this month:
>
> http://mail-archives.apache.org/mod_mbox/synapse-dev/200806.mbox/%3cA9856B86EDA25144A734574D0338C135EEFB71@berwnexmb01.jcorp.ad.jamba.net%3e
>
> It would be interesting for me to hear what you think about this as well,
> and how this may interfere with your planned improvements.I don't think
> there is much overlapping, but I maybe wrong.
>
> Regards,
> Eric
>
> ________________________________
>
> Von: Afkham Azeez [mailto:afkham@gmail.com]
> Gesendet: Fr 13.06.2008 07:28
> An: dev@synapse.apache.org
> Betreff: Re: Intelligent Synapse Load Balancer
>
>
> Paul,
> I have planned this for a future iteration. This is actually a different
> load balancing algorithm, where if a perceived load of a node is high, we
> abstain from sending further requests to it until it recovers. We should be
> able to plug this into the currently available LB or the new LB I'm writing.
> I have also planned to dynamically fire-up new application nodes when the
> load increases. I guess the term intelligent LB may be misleading and a
> better term would be dynamic LB or HA LB. So indeed, we can abstract away
> the idea of "which systems are available and how much load can they accept"
> into the LB algorithm, which is consistent with the current design and
> implementation.
>
>
> <sequence name="main" onError="errorHandler">
> <in>
> <send>
> <endpoint>
> <intelligentLoadbalance failover="true"
> algorithm="intelligent"/>
> </endpoint>
> </send>
> <drop/>
> </in>
> <out>
> <send/>
> </out>
> </sequence>
>
> Thanks
> Azeez
>
>
> On Fri, Jun 13, 2008 at 3:34 AM, Paul Fremantle <pz...@gmail.com> wrote:
>
>
> Azeez
>
> I guess I'm probably misunderstanding your proposal. I have a
> feeling
> that what you are proposing supports what I want, but maybe in a
> slightly different syntax and model.
>
> Maybe if I explain what I'm thinking you can map what you are
> proposing onto it and then I'll understand it better.
>
> My understanding of how intelligent load balancers communicate with
> endpoints is that there is usually some form of plugpoint that
> allows
> the loadbalancer to know which endpoints are available and in what
> proportion to send requests to those endpoints.
>
> So for example, the load balancer may call an API:
>
> EndpointReport getEndpoints("serviceX");
>
> where EndpointReport will be a map of endpoints and a weighting:
>
> {
> "192.168.2.1 <http://192.168.2.1/> " -> 65%
> "192.168.2.2 <http://192.168.2.2/> " -> 35%
> }
>
> Typically underneath this API is some kind of information gathering
> system. There are three usual systems: (1) access to the application
> running on the endpoint (so this corresponds to getting information
> directly from the Axis2 group communications), (2) running an
> OS-level
> agent on the system that monitors CPU, Memory and IO, or (3) pinging
> systems and seeing how fast they respond.
>
> So I guess I'm thinking that this abstraction should not assume
> there
> is a group communication system but simply abstract away the idea of
> "which systems are available and how much load can they accept".
>
> Paul
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
--
Thanks
Afkham Azeez
http://afkham.org
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
AW: Intelligent Synapse Load Balancer
Posted by "Hubert, Eric" <er...@jamba.net>.
Hi Azeez,
your explanations sounds reasonable to me. I also like the idea of renaming your proposal from intelligentLoadbalance to something like dynamicLoadbalance as this describes the way in which the actual members of the LB group are discovered. The algorithm is responsible for the actual distribution of the load (currently only roundRobin in Synapse, but his can be improved).
Regarding some improvents to current loadbalancing I wrote a mail to the list some time back early this month:
http://mail-archives.apache.org/mod_mbox/synapse-dev/200806.mbox/%3cA9856B86EDA25144A734574D0338C135EEFB71@berwnexmb01.jcorp.ad.jamba.net%3e
It would be interesting for me to hear what you think about this as well, and how this may interfere with your planned improvements.I don't think there is much overlapping, but I maybe wrong.
Regards,
Eric
________________________________
Von: Afkham Azeez [mailto:afkham@gmail.com]
Gesendet: Fr 13.06.2008 07:28
An: dev@synapse.apache.org
Betreff: Re: Intelligent Synapse Load Balancer
Paul,
I have planned this for a future iteration. This is actually a different load balancing algorithm, where if a perceived load of a node is high, we abstain from sending further requests to it until it recovers. We should be able to plug this into the currently available LB or the new LB I'm writing. I have also planned to dynamically fire-up new application nodes when the load increases. I guess the term intelligent LB may be misleading and a better term would be dynamic LB or HA LB. So indeed, we can abstract away the idea of "which systems are available and how much load can they accept" into the LB algorithm, which is consistent with the current design and implementation.
<sequence name="main" onError="errorHandler">
<in>
<send>
<endpoint>
<intelligentLoadbalance failover="true" algorithm="intelligent"/>
</endpoint>
</send>
<drop/>
</in>
<out>
<send/>
</out>
</sequence>
Thanks
Azeez
On Fri, Jun 13, 2008 at 3:34 AM, Paul Fremantle <pz...@gmail.com> wrote:
Azeez
I guess I'm probably misunderstanding your proposal. I have a feeling
that what you are proposing supports what I want, but maybe in a
slightly different syntax and model.
Maybe if I explain what I'm thinking you can map what you are
proposing onto it and then I'll understand it better.
My understanding of how intelligent load balancers communicate with
endpoints is that there is usually some form of plugpoint that allows
the loadbalancer to know which endpoints are available and in what
proportion to send requests to those endpoints.
So for example, the load balancer may call an API:
EndpointReport getEndpoints("serviceX");
where EndpointReport will be a map of endpoints and a weighting:
{
"192.168.2.1 <http://192.168.2.1/> " -> 65%
"192.168.2.2 <http://192.168.2.2/> " -> 35%
}
Typically underneath this API is some kind of information gathering
system. There are three usual systems: (1) access to the application
running on the endpoint (so this corresponds to getting information
directly from the Axis2 group communications), (2) running an OS-level
agent on the system that monitors CPU, Memory and IO, or (3) pinging
systems and seeing how fast they respond.
So I guess I'm thinking that this abstraction should not assume there
is a group communication system but simply abstract away the idea of
"which systems are available and how much load can they accept".
Paul
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
Paul,
I have planned this for a future iteration. This is actually a different
load balancing algorithm, where if a perceived load of a node is high, we
abstain from sending further requests to it until it recovers. We should be
able to plug this into the currently available LB or the new LB I'm writing.
I have also planned to dynamically fire-up new application nodes when the
load increases. I guess the term intelligent LB may be misleading and a
better term would be dynamic LB or HA LB. So indeed, we can abstract away
the idea of "which systems are available and how much load can they accept"
into the LB algorithm, which is consistent with the current design and
implementation.
<sequence name="main" onError="errorHandler">
<in>
<send>
<endpoint>
*<intelligentLoadbalance failover="true"
algorithm="intelligent"/>*
</endpoint>
</send>
<drop/>
</in>
<out>
<send/>
</out>
</sequence>
Thanks
Azeez
On Fri, Jun 13, 2008 at 3:34 AM, Paul Fremantle <pz...@gmail.com> wrote:
> Azeez
>
> I guess I'm probably misunderstanding your proposal. I have a feeling
> that what you are proposing supports what I want, but maybe in a
> slightly different syntax and model.
>
> Maybe if I explain what I'm thinking you can map what you are
> proposing onto it and then I'll understand it better.
>
> My understanding of how intelligent load balancers communicate with
> endpoints is that there is usually some form of plugpoint that allows
> the loadbalancer to know which endpoints are available and in what
> proportion to send requests to those endpoints.
>
> So for example, the load balancer may call an API:
>
> EndpointReport getEndpoints("serviceX");
>
> where EndpointReport will be a map of endpoints and a weighting:
>
> {
> "192.168.2.1" -> 65%
> "192.168.2.2" -> 35%
> }
>
> Typically underneath this API is some kind of information gathering
> system. There are three usual systems: (1) access to the application
> running on the endpoint (so this corresponds to getting information
> directly from the Axis2 group communications), (2) running an OS-level
> agent on the system that monitors CPU, Memory and IO, or (3) pinging
> systems and seeing how fast they respond.
>
> So I guess I'm thinking that this abstraction should not assume there
> is a group communication system but simply abstract away the idea of
> "which systems are available and how much load can they accept".
>
> Paul
>
> On Thu, Jun 12, 2008 at 10:39 PM, Afkham Azeez <af...@gmail.com> wrote:
> > 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 <pz...@gmail.com>
> 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 <af...@gmail.com> wrote:
> >> >
> >> >
> >> > On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com>
> >> > 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 <af...@gmail.com>
> >> >> 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
> >> >> paul@wso2.com
> >> >>
> >> >> "Oxygenating the Web Service Platform", www.wso2.com
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >> >> For additional commands, e-mail: dev-help@synapse.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >> For additional commands, e-mail: dev-help@synapse.apache.org
> >>
> >
> >
> >
> > --
> > 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
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Thanks
Afkham Azeez
http://afkham.org
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: Intelligent Synapse Load Balancer
Posted by Paul Fremantle <pz...@gmail.com>.
Azeez
I guess I'm probably misunderstanding your proposal. I have a feeling
that what you are proposing supports what I want, but maybe in a
slightly different syntax and model.
Maybe if I explain what I'm thinking you can map what you are
proposing onto it and then I'll understand it better.
My understanding of how intelligent load balancers communicate with
endpoints is that there is usually some form of plugpoint that allows
the loadbalancer to know which endpoints are available and in what
proportion to send requests to those endpoints.
So for example, the load balancer may call an API:
EndpointReport getEndpoints("serviceX");
where EndpointReport will be a map of endpoints and a weighting:
{
"192.168.2.1" -> 65%
"192.168.2.2" -> 35%
}
Typically underneath this API is some kind of information gathering
system. There are three usual systems: (1) access to the application
running on the endpoint (so this corresponds to getting information
directly from the Axis2 group communications), (2) running an OS-level
agent on the system that monitors CPU, Memory and IO, or (3) pinging
systems and seeing how fast they respond.
So I guess I'm thinking that this abstraction should not assume there
is a group communication system but simply abstract away the idea of
"which systems are available and how much load can they accept".
Paul
On Thu, Jun 12, 2008 at 10:39 PM, Afkham Azeez <af...@gmail.com> wrote:
> 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 <pz...@gmail.com> 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 <af...@gmail.com> wrote:
>> >
>> >
>> > On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com>
>> > 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 <af...@gmail.com>
>> >> 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
>> >> paul@wso2.com
>> >>
>> >> "Oxygenating the Web Service Platform", www.wso2.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> >> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > 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
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> 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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
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 <pz...@gmail.com> 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 <af...@gmail.com> wrote:
> >
> >
> > On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com>
> 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 <af...@gmail.com>
> 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
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >> For additional commands, e-mail: dev-help@synapse.apache.org
> >>
> >
> >
> >
> > --
> > 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
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Thanks
Afkham Azeez
http://afkham.org
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: Intelligent Synapse Load Balancer
Posted by Paul Fremantle <pz...@gmail.com>.
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 <af...@gmail.com> wrote:
>
>
> On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com> 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 <af...@gmail.com> 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
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> 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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
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 <ru...@gmail.com>
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 <af...@gmail.com> 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 <af...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com>
>>> 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 <af...@gmail.com>
>>>> 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
>>>> paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
Re: Intelligent Synapse Load Balancer
Posted by Ruwan Linton <ru...@gmail.com>.
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 <af...@gmail.com> 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 <af...@gmail.com> wrote:
>
>>
>>
>> On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com> 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 <af...@gmail.com> 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
>>> paul@wso2.com
>>>
>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>>
>>
>>
>> --
>> 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"
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
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 <af...@gmail.com> wrote:
>
>
> On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com> 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 <af...@gmail.com> 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
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
>
> --
> 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
Re: Intelligent Synapse Load Balancer
Posted by Afkham Azeez <af...@gmail.com>.
On Wed, Jun 11, 2008 at 6:18 PM, Paul Fremantle <pz...@gmail.com> 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 <af...@gmail.com> 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
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Thanks
Afkham Azeez
http://afkham.org
http://www.wso2.org
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: Intelligent Synapse Load Balancer
Posted by Paul Fremantle <pz...@gmail.com>.
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.
Paul
On Wed, Jun 11, 2008 at 12:47 PM, Afkham Azeez <af...@gmail.com> 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
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org