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
