geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: failover demo in sandbox
Date Tue, 26 Jan 2010 13:42:18 GMT

On Jan 21, 2010, at 8:21 PM, David Blevins wrote:

> On Jan 21, 2010, at 7:49 PM, David Blevins wrote:
>> On Jan 20, 2010, at 12:15 AM, Kevan Miller wrote:
>>> 3) Geronimo currently requires multicast for the failover  
>>> scenario. This is great. However, we should also offer unicast- 
>>> based support, also. I frequently encounter users who are unable  
>>> to use multicast in their environments. Providing unicast support  
>>> would be a valuable addition, I think.
>> Agreed.
>> Currently with the way that everything is designed we theoretically  
>> only need to replace this class:
>> Which is an implementation of the DiscoveryAgent interface.  The  
>> primary job of the DiscoveryAgent is to receive notifications about  
>> services coming and going and then simply notify the other parts of  
>> the system that are interested in this information.  These "other  
>> parts" implement this interface:
>> public interface DiscoveryListener {
>>     public void serviceAdded(URI service);
>>     public void serviceRemoved(URI service);
>> }
>> So basically the new DiscoveryAgent needs to have a way to receive  
>> "service added" and "service removed" messages and send that info  
>> to the listener.
>> It seems that a REST implementation of DiscoveryAgent would be very  
>> useful as a lot of shops use it quite extensively already for  
>> various administration and it actually lines up pretty close.   
>> ServiceAdded might be a PUT and serviceRemoved a DELETE.
>> Seems with something that simple it wouldn't be too hard to do  
>> anything else that's required to get it to broadcast around.
> Another approach we could take is a DiscoveryAgent implementation  
> that is backed by a JMS Topic.  It would be a closer match to  
> Multicast, though we'd have to do some additional work to figure out  
> how to ensure that the JMS Broker is not a single point of failure.   
> Having it be a single point of failure initially would be fine, but  
> we would eventually need to figure that out.  ActiveMQ does have  
> some features in this regard, so it should  hopefully be workable.
> One option.
> Bottom line is all we use multicast for is to move URLs around the  
> network, so some way to do that without multicast is all we need.

Just checking in on this.  Was hoping to start a conversation that  
might lead to deciding on an approach (REST vs JMS vs ?).


View raw message