"the best load balanced solution"? how is that?
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.
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.
I think the problem is more complex than asking for a URL collection
and "pick one".
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
>>>>>>
>>>>
>>
--
Paulo Lopes
www.scratchydreams.com
