Good Ideas Manu and Paulo. But what Paulo suggested is a sort of centralized load balancing, but I would suggest a de-centeralized load balancing. I am not so experienced in this subject, but lets say that these info about all servers and their load are distributed and shared among all servers in the cluster, so if a client sends a request to a server, even if it is the initial server of this client, the server can decide that it has to dispatch this request to another un-loaded server to serve the request, this way we can guarantee that these info are available even if we have one node in the cluster, cause the SD may go down too like any other server in the cluster. I suggest that we have to document all this brain storming outcomes, and to start with the simple scenario Jeff explained in his first mail in this thread. comments ???
On 6/14/07, Manu George <[EMAIL PROTECTED]> 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. 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
