Yep...I think a pluggable policy is the way to go. Jeff
Mohammad Nour El-Din wrote: > 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 >> >>>>> >> >>> >> > >> >> > >
