Awesome! Your help would be very much appreciated. I am flushing out the API now and I can post a patch (or just commit it) and we can alter it as need be.
Should we start by talking about the SPI/API and maybe just start posting the interfaces? Jeff Mohammad Nour El-Din wrote: > Cool, do u have anything implemented yet or u still working on that ? Cauze > I want to save us some time, and try to put test cases for it first - if > applicable - before going into any implementation, so every bit of code of > this issue can be tested peoperly. Cauze sometimes we do the reverse and > implement something then test it, and we may find ourselves not being able > to test, may be cauze of the way we implemented it. > > On 6/14/07, Jeff Genender <[EMAIL PROTECTED]> wrote: >> >> 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 >> >> >>>>> >> >> >>> >> >> > >> >> >> >> >> > >> > >> > > >
