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.


Currently with the way that everything is designed we theoretically only need to replace this class:


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.


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 ?