On 21/07/2004 5:28 PM, [EMAIL PROTECTED] wrote:
For clustering, we've been working quite heavily for some time on this abstraction...
http://activecluster.codehaus.org/
(Note that ActiveCluster is not Geronimo specific and so can be used to build clusters or anything).
The current implementation works on top of any JMS provider, such as ActiveMQ, which can work over UDP, multicast, TCP, SSL, g-network, JGroups, JXTA etc.
As far as I know, ActiveCluster does not provide high-availability on top of any JMS server. JMS servers are not designed equally from an high-availability point-of-view. Some of them are high-available and others aren't. For instance, if the JMS server used by ActiveCluster fails, then it is the cluster as a whole which is down.
Surely its up to the JMS provider to provide HA - not the clustering abstraction you're using to write cluster based protocols?
FWIW we're using ActiveCluster with ActiveMQ to make HA JMS brokers. ActiveCluster doesn't need to be HA - its a tool for building HA :)
So, ActiveCluster does not turn any JMS provider into an highly-available JMS provider and if the JMS provider fails, then the cluster as a whole fails.
Yes. You've gotta have a single point of failure somewhere and the ActiveCluster *provider* which may or may not be a JMS provider, is meant to handle this.
But you typically don't need HA for ActiveCluster as its mostly a discovery & lightweight state-replication protocol. Its there to discover nodes, not be a JMS server. HA protocols are developed behind different APIs (JMS, RMI, JNDI, JDBC etc)
Jules has been working hard on distributed session state and handling fail-over gracefully and cluster wide topology organisation protocols such as for arranging buddies over subnets / DR zones and the like using WADI
http://wadi.codehaus.org/
which is using ActiveCluster and Jules is starting to put together various algorithms for choosing buddies, pairs, sub-nets, controllers and the like.
Notice the simpler API for ActiveCluster which just reuses a few interfaces from JMS.
It seems your new messaging.cluster API is pretty similar to ActiveCluster. Any ideas why you didn't just use ActiveCluster? (Especially as I mentioned it to you quite a while ago :)
I know. Actually, I was so closed to reach a presentable state of g-messaging that I have done the last step: at this very moment, N servers can be started and the proto will auto-discover and syndicate them. There is not a single point of failure. Actually this is wrong as a "migratable" service is executed by a server and not migrated to another node upon failure. This is a standard feature that should be provided out-of-the-box: the ability to run a service only once in a cluster and migrate it on demand/failure to another node.
And for some time ActiveCluster has been implemented using UDP / multicast, g-messaging or jgroups with no single point of failure too...
Also, as I said to you a while ago, I don't see why the messaging package doesn't use the JMS API for things like Msg / MsgBody / MsgConsumer / MsgProducer and so forth. Not only would this mean your API would become more J2EE standard, it'd mean you could reuse heaps of open source and commercial implementations.
At the very beginning, I was really seduced by this idea. On second thought, I prefer this simplified API.
Msg / MsgBody / MsgHeader is simpler than javax.jms.Message?
No cumbersome JMSException at each and every simple call on a JMS Message. One can see the various MsgX as wrappers around the JMS API. Actually, any open source or vendor provided JMS implementations could be re-used: the org.apache.geronimo.messaging.remotenode is done to hook-in others transports such as JMS. As an aside, we are talking here about only 5 classes in a code base couting the little more than 100 classes.
Hmm. A whole new API to avoid a checked exception? Given that we're talking about messaging/clustering code here where exceptions can be thrown at any time, I'm not sure hiding exceptions is such a great idea. (Sure at the POJO layer this can be handy, but we're lower level communications code here that needs to be aware that lots of things can fail).
Having said all that, I am still having a serious look to ActiveCluster. However, I do not see how its current implementation avoids a cluster wide failure in case of a JMS server failure.
ActiveCluster doesn't need to use a JMS server - indeed we recommend you don't use a JMS server to implement it. We use it today using UDP / multicast / g-messaging / jgroups without a JMS server or single point of failure. If you had a HA JMS you could use that too. Or you could write a native ActiveCluster implementation without using a JMS provider at all.
James ------- http://radio.weblogs.com/0112098/
