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 Thu, 28 Jan 2010 00:20:35 GMT

On Jan 27, 2010, at 8:44 PM, Kevan Miller wrote:

> On Jan 26, 2010, at 8:42 AM, David Blevins wrote:
>> 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 ?).
> Sorry. I read but forgot to get back to it... Need a better TO DO  
> system, I guess.
> Personally, I wouldn't want to require a JMS broker or even a web  
> container in a farm node, but maybe that's not what you're suggesting?
> I'd think that an administratively-defined static configuration  
> would be a starting point for this...

Each node needs a current list of people in the cluster, and it's the  
job of the DiscoveryAgent to let the node know when people come and go.

However statically the initial list is created and given to a node, we  
still need a dynamic way to update it and for the DiscoveryAgent in  
each node to "see" it: push vs pull doesn't matter.  Anything dynamic  
will work, but this one part has to be dynamic.

Some pull ideas:
   - poll a file on a shared drive
   - poll a url, basic txt webpage
   - poll a db (yuck)
   - poll a service (rest, rmi, jms)

Some push ideas:
   - RMI service on node
   - REST or HTTP service on node
   - JMS (sort of both push and pull)


View raw message