Paulo Lopes 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).
This not a correct assumption, there has to be discovery to make this work or one could not effectively cluster w/o figuring out who is active and in 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. > I'm not sure I agree here. I think a policy would be sent and the client stub can act in a DNS round-robin fashion or pick a server at random, with the second being that it can effectively load-balance. When the inital JNDI context is contacted, the client is given an initial list, it can just randomly pick the first ejb server to make contact with. > 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). > Centralized server would not be prudent as its a single point of failure and we are now enforcing a clustering implementation on this as opposed to a SPI/API to plug clustering implementations into it. > 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
