geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Geronimo cluster API suggestion
Date Thu, 13 Jul 2006 17:30:36 GMT
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


View raw message