geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: sandbox/messaging - your feedbacks are welcome
Date Wed, 21 Jul 2004 11:22:03 GMT
On 21/07/2004 5:28 PM, jastrachan@mac.com 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

Mime
View raw message