On 6/15/07, Paulo Lopes <[EMAIL PROTECTED]> wrote:
"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.
May be we can use weights based on the current server load (may be based on some other factors too) to determine the probabilities for directing the next request to the server randomly. For example, if server1 is serving 80 requests and server2 20, then you direct the next request to server1 with 20% (= 1 - (80 / (80+20)) probability and server2 with 80%. Vamsi
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
