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 <[EMAIL PROTECTED]> 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/[EMAIL
> PROTECTED]
>
> 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:[EMAIL PROTECTED]
> Gesendet: Fr 13.06.2008 07:28
> An: [email protected]
> 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 <[EMAIL PROTECTED]> 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: [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
