Paulo Lopes wrote:
> "the best load balanced solution"? how is that?
>
Its the best out of the two we have discussed thus far.
> Let me start with round robin:
>
> imagine you have OEJBServer1 and OEJBServer2 (in the cluster) and now
> you have like N clients OEJBClient(i).
>
> Say that all the clients only know at start OEJBServer1 and ask then
> the server list:
>
> inside OEJBClient(i) code you have:
> OEJBServer1.getMeTheServerList()
> // this returns a collection with: {OEJBServer1, OEJBServer2}
>
> using the round robin: when asking for the next server all clients will
> execute:
> theClusterServerList.getNextServer();
> // bad enough for each OEJBClient(i) the answer will be OEJBServer1 to
> every (i)
>
> This leads to a never used OEJBServer2 and an overloaded OEJBServer1.
>
You are making an assumption that the server is not delivering a random
list of the URLs. This is easily mitigated.
> Now with Random policy:
>
> When asking for what next server each client might get either a 1 or a
> 2, this spreads the load, but if server1 is for instance already
> serving 1000 requests and server2 5, there is 50% of change that the
> next request goes to server1 who is already overloaded and server2
> stays free.
>
Explain the probabilities in a random pick how server1 will be accepting
1000 requests and server 2 only 5? Now the possibility exists that such
a situation could occur, but the probability...I think I have a better
chance of winning the lottery.
In addition, if someone has a single server servicing 1000 simultaneous
clients for remote EJB, I think they probably need to have more than 2
servers in the cluster ;-)
> I think the problem is more complex than asking for a URL collection
> and "pick one".
Ok...so people have offered up 2 possible policies to start with. Given
the size of putting this together, I believe 2 simple policies for
clustering to get it working is not too bad to begin with. A random
policy will probably be sufficient for 98% of the use cases out there
that would use this. The policy can be a simple SPI that is pluggable
and can be expanded upon. If you have a more robust implementation that
you would like to see in it, then please offer your ideas so they are
tracked here.
IMHO, we can always build a better mouse trap, but we need to start with
something simple that works.
Yes the servers could easily come up with an ordering based on load,
deliver *that* list to the clients, and they can round-robin that list.
Again...for a pluggable policy, its rather simple to implement.
The key here is to flush out the basic protocol for communicating a
list...some list...to the clients. How it fails over, etc, can be done
at the point of implementation.
Jeff
>
> On 6/14/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Right...I would agree random is best as the default since it utilizes
>> the best load balanced solution.
>>
>> Jeff
>>
>> David Blevins wrote:
>> >
>> > On Jun 14, 2007, at 10:54 AM, Jeff Genender wrote:
>> >>
>> >> Manu George wrote:
>> >>> Yes I understand that random will work but how about others like
>> round
>> >>> robin etc? Are we planning to support only the random strategy?
>> >>
>> >> I think we can support whatever policy we want since this is a
>> component
>> >> of OEJB and not the clustering implementation that is bolted on to it.
>> >> Round robin and random are both fairly simple to implement.
>> >
>> > Round robin super easy to implement and definitely should be an option.
>> > Random seems more appealing as the default, we can just:
>> >
>> > URL nextServer = serverList.get(new
>> > Random().nextInt(serverList.size()));
>> >
>> > -David
>> >
>> >>
>> >> Jeff
>> >>
>> >>
>> >>
>> >>>
>> >>> On 6/14/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> >>>>
>> >>>>
>> >>>> Manu George wrote:
>> >>>>> As per what I understood if one of the servers are down then the
>> >>>>> client will call the next one in the list which would send it a
>> new id
>> >>>>> after which all calls will be to that one.
>> >>>>
>> >>>> You are assuming no policy for how a client chooses a server and
>> that
>> >>>> its linear. Consider it random and this issue goes away.
>> >>>>
>> >>>>> But in order to decide
>> >>>>> which server to pick based on the load balancing strategy used I
>> think
>> >>>>> we may need more information to be passed to the client. Once this
>> >>>>> discussion is finished i think we should put this in a wiki page
>> as it
>> >>>>> provides good insights on clustering and the logic used. I can
>> >>>>> probably do that if no one else wants it :)
>> >>>>>
>> >>>>> Regards
>> >>>>> Manu
>> >>>>>
>> >>>>> On 6/14/07, Paulo Lopes <[EMAIL PROTECTED]> wrote:
>> >>>>>> The idea of id download on the first connection doesn't seem
>> nice to
>> >>>>>> me. Assume the following scenario:
>> >>>>>>
>> >>>>>> you have a cluster of 3 servers, and the 3 are aware of the
>> other by
>> >>>>>> their internal configuration. (no discovery inside the
>> cluster). The
>> >>>>>> client receives the list of 3 servers and now has to decide
>> which one
>> >>>>>> to connect. It is clear here that the client needs to know some
>> more
>> >>>>>> about the server to decide which one to pick in order to share the
>> >>>>>> load balancing in the cluster, more there is no way for the
>> client to
>> >>>>>> know if one of the servers is down and if it is that server is
>> >>>>>> removed
>> >>>>>> from the list and never connected again during that request.
>> >>>>>>
>> >>>>>> My idea is that perhaps we would better have a small extra server
>> >>>>>> that
>> >>>>>> i will call a service dispatcher, that is the central point for
>> the
>> >>>>>> cluster. no need to change the openejb code each server still
>> >>>>>> works in
>> >>>>>> a isolated way. The SD would have the configurations of where the
>> >>>>>> openejb nodes are in the cluster and their status (up/down).
>> >>>>>>
>> >>>>>> The clients would then connect to the SD and the SD would query
>> the
>> >>>>>> list of servers, and forward to the next available one. Metrics
>> could
>> >>>>>> be gathered from the SD such as time between query and response
>> from
>> >>>>>> OEJB making a simple (not so accurate) load balancer system.
>> >>>>>>
>> >>>>>> Paulo
>> >>>>>>
>> >>>>
>> >>
>>
>
>
