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.
If ActiveCluster yields clients of this problem by using a ConnectionFactory, which uses under the cover N ConnectionFactory to N distinct JMS servers or if it has the ability to detect the failure of a JMS server and migrates it on another node, then yes it supports high-availability.
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.
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.
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. 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.
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.
Cheers, Gianny
