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 >>>>>> >>>> >>
