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
