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