geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: failover demo in sandbox
Date Wed, 27 Jan 2010 19:44:41 GMT

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:
>>> 
>>> org.apache.geronimo.farm.discovery.MulticastDiscoveryAgent
>>> 
>>> 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.
>> 
>> http://activemq.apache.org/how-do-distributed-queues-work.html
>> 
>> 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... 

--kevan
Mime
View raw message