geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: Geronimo cluster API suggestion
Date Thu, 13 Jul 2006 18:24:43 GMT

Thanks for the first pass on looks interesting.


Filip Hanik - Dev Lists wrote:
> Ladies and Gentlemen,
> from our talk at Dublin clustering BOF, clustering is not always about
> state replication, there are other aspects of it, and its those I am
> focusing on here, as state replication is already being talked about in
> another thread, so it has enough coverage in the Session API threads.
> This API is aimed for any underlying implementation to allow different
> components to know of each other, my most simple example was the
> InitialContext, to be able to fail over between two Geronimo instances,
> the initial context on the client could either
> a) - hard code the locations of the Geronimo VM(s)
> b) - dynamically discover the locations of the Geronimo VM(s)
> c) - being able to receive node information from "a" Geronimo VM
> jboss does option A and B, and I am not sure about C,
> but its the C option i am trying to address, as that would allow for
> heterogeneous clusters, as not every VM would have the same services
> deployed, and the client shouldn't have to know what services are
> deployed where.
> So the invocation would be something like
> InitialContext ic = new InitialContext(properties); (properties could be
> any of options A,B,C from above)
> Context ctx = (Context)ic.lookup(sub context);
> SomeRemoteStub stub = ctx.lookup("my/remotestub");
> in a non clustered scenario, the ic.lookup always happens on the node
> initialized in the "new InitialContext(properties);" call, and the "ctx"
> is just talking to that same node.
> However, in a heterogeneous cluster, all three, "ic", "ctx" and "stub"
> could be cluster-aware, and make decisions through that.
> Simple example, we want to lookup ejbX on a cluster with servers
> serverA..serverZ, ejbX is only deployed on serverD..serverF.
> InitialContext ic = new InitialContext("serverA, serverG, serverT");
> //hand pick a few servers if automatic discovery is disabled(option C)
> EjbX ejbX = ic.lookup("my/company/ejbX");
> because ic, is cluster aware, and it is able to determine what services
> run on what parts of the cluster, it can fetch the stub from serverD, or
> it retrieves the stub from serverA who retrieved it from serverD.
> and now the ejbX stub is pinned to serverD (or it can be load balanced,
> up to the EJB implementation, see next line)
> if the ejb stub is cluster aware, means it can also fail over to serverE
> or serverF if serverD goes down.
> remember, there is no state replication in these examples, simply an
> intelligent way to distribute load, also, there is no mention of how
> this is actually implemented, just the API used.
> So after this long rant, and for those still with me, thanks for your
> patience, I see a need for an API where components like
> JNDI/EJB/monitoring etc would have the need for some sort of API to
> retrieve information about the cluster (or group if you wish to call it
> that), so no matter what the underlying clustering implementation is.
> The API I am proposing is aimed to be useful and simple for both the
> cluster provider and the cluster user. So no fancy mechanism that
> tribes,activecluster,appia,jgroups implement are exposed in here, but
> all of them could implement this API. Components like JNDI,monitoring
> can decide to use this API, which any underlying implementation would be
> required to support, or they could plug in directly to the implementation.
> I believe the main benefit of this API, could be to have one cluster
> notion for the VM, instead of one per component.
> Quick Explanation of the API:
> Cluster - One instance per VM
> Node - represents the location and state of a VM
> Channel - a communication channel in a cluster, a cluster can support
> more than one active channel, so that components wouldn't have to listen
> in on each other's chatter
> Message - a message to be sent (this is not a serializable message,
> implementations and components can send byte[] if they want, it will
> just be kept in this message)
> That's all folks
> Filip

View raw message