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 <[email protected]> wrote: > > > 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 > -- Shawn
