On Thu, Jan 28, 2010 at 8:20 AM, David Blevins <[email protected]>wrote:
>
> 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:
>>>>>
>>>>> 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...
>>
>
> 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.
I know that it'd be better that there's a dynamic discovery mechanism
here. But AFAIK, current WADI web and Tomcat native clustering does not
support dynamic unicast discovery at all.
Can we just start with a statical initial list for a given cluster with
known nodes, without dynamic discovery for now ?
> Anything dynamic will work, but this one part has to be dynamic.
> Some pull ideas:
> - poll a file on a shared drive
>
Is this depends on the OS level sharing ?
> - poll a url, basic txt webpage
>
This depends on a web server.
> - poll a db (yuck)
>
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)
>
Jms will require brokers, Maybe RMI is a plausible solution.
How would rest be implemented here ?
>
>
> -David
>
>
>
--
Shawn
