geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Jiang <genspr...@gmail.com>
Subject Re: failover demo in sandbox
Date Mon, 01 Feb 2010 03:25:31 GMT
I added some windows script to enable the windows support for failover
example, will check in after some cleanup.

On Thu, Jan 28, 2010 at 11:05 AM, Shawn Jiang <genspring@gmail.com> wrote:

>
>
> On Thu, Jan 28, 2010 at 8:20 AM, David Blevins <david.blevins@visi.com>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
>



-- 
Shawn

Mime
View raw message