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. Anything dynamic
will work, but this one part has to be dynamic.
Some pull ideas:
- poll a file on a shared drive
- poll a url, basic txt webpage
- poll a db (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)
-David
