geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: sandbox/messaging - your feedbacks are welcome
Date Wed, 21 Jul 2004 12:30:08 GMT
On 21 Jul 2004, at 12:22, Gianny Damour wrote:
> On 21/07/2004 5:28 PM, wrote:
>> For clustering, we've been working quite heavily for some time on 
>> this abstraction...
>> (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
>> 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 

>> 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 

> 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.


View raw message