On 6/14/07, David Blevins <[EMAIL PROTECTED]> 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()));
I am thinking of a more generic solution that can help us now and later when
we try to make things more complex for real load balancing. I mean the
server list can contain more info about the servers like weights for example
and the client will have an instance of a policy which will take the server
list and returns the server with which the client is going to communictate
like this
/*
* We will assume that we have an instance of the RoundRobin policy
*/
URL requestHandlerServer = policy.getServer(serverList);
In case of the Round Robin policy it will do just like David said. And it
can do more
complicated server election algorithm. Comments ???
-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
>>>>>
>>>
>
--
Thanks
- Mohammad Nour
