Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 46504 invoked from network); 1 Feb 2010 03:26:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Feb 2010 03:26:02 -0000 Received: (qmail 14385 invoked by uid 500); 1 Feb 2010 03:26:01 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 14292 invoked by uid 500); 1 Feb 2010 03:26:01 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 14284 invoked by uid 99); 1 Feb 2010 03:26:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Feb 2010 03:26:01 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of genspring@gmail.com designates 209.85.216.203 as permitted sender) Received: from [209.85.216.203] (HELO mail-px0-f203.google.com) (209.85.216.203) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Feb 2010 03:25:52 +0000 Received: by pxi41 with SMTP id 41so3950930pxi.27 for ; Sun, 31 Jan 2010 19:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=RFpiOOl+2M66VY1lQZX0oza76F81GXewPbeQfF6vW/w=; b=pXp08JIkHnfJ0Hr4JYGfX70tI01U6CyGLBDpyl1JiUNSbOa9Jauaqs5MHtdf5mcEqa ASv2FJVTYjZmYSj+i4ukWUnKa7Tt2e09W0vj+0Aw9Sm8SZfXjmpjrXu1wWZqarQ+In8p QMqylb0PaIq8Ifjw7cvR7LcpmlHwX92vRDkI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=V16zctatsBSQtu+fGExJyftF3Raf2Jz4owvuZOzHzmwUEnif+fLJnXOSnaH5wPNHBw d6KdbFvCopsyQ8by+BFAv0RULvVaLw/LikToLjTOGQSffu3q/Ld91Y/cfr1sEL5yUpNi 4sH0HzUM/La4sAjnv0XiHZ3v+pT4JQsyhZ1dY= MIME-Version: 1.0 Received: by 10.141.2.2 with SMTP id e2mr2730220rvi.274.1264994731467; Sun, 31 Jan 2010 19:25:31 -0800 (PST) In-Reply-To: References: <37D0FC3D-0C6F-4FF5-A9D5-2076E53CADF6@gmail.com> <123CD9EF-9EFB-4109-98F4-4BA234535F08@visi.com> <8A85DE86-55CB-463F-9F01-636849EDFBA4@visi.com> <0A23BC8A-A83E-4332-9DF3-E99A64C4C17A@visi.com> <6D9FAF08-2EEE-4CC3-9BFE-AB15486AC005@visi.com> Date: Mon, 1 Feb 2010 11:25:31 +0800 Message-ID: Subject: Re: failover demo in sandbox From: Shawn Jiang To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=000e0cd117689ca5a4047e818970 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd117689ca5a4047e818970 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > > > On Thu, Jan 28, 2010 at 8:20 AM, David Blevins 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 --000e0cd117689ca5a4047e818970 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I added some windows script to enable the windows support for failover exam= ple, 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 freque= ntly 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 ne= ed to replace this class:

org.apache.geronimo.farm.discovery.MulticastDiscoveryAgent

Which is an implementation of the DiscoveryAgent interface. =A0The 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 in= terested in this information. =A0These "other parts" implement th= is interface:

public interface DiscoveryListener {
=A0public void serviceAdded(URI service);
=A0public void serviceRemoved(URI service);

}

So basically the new DiscoveryAgent needs to have a way to receive "se= rvice added" and "service removed" messages and send that in= fo 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 administrati= on and it actually lines up pretty close. =A0ServiceAdded might be a PUT an= d 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 b= acked by a JMS Topic. =A0It 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. =A0Having it be a single poin= t of failure initially would be fine, but we would eventually need to figur= e that out. =A0ActiveMQ does have some features in this regard, so it shoul= d =A0hopefully 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. =A0Was 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 conta= iner in a farm node, but maybe that's not what you're suggesting?
I'd think that an administratively-defined static configuration would b= e a starting point for this...

Each node needs a current list of people in the cluster, and it's the j= ob of the DiscoveryAgent to let the node know when people come and go.=A0

However statically the initial list is created and given to a node, we stil= l need a dynamic way to update it and for the DiscoveryAgent in each node t= o "see" it: push vs pull doesn't matter. =A0

I know that it'd be better that there's a dynamic discovery=A0 = mechanism here.=A0 But AFAIK, current WADI web and Tomcat native clustering= does not support dynamic unicast discovery at all.=A0

Can we just = start with a statical initial list for a given cluster with known nodes,=A0= without dynamic discovery for now ?

=A0
Anything dynamic will work, but this one part has to be dynam= ic.=A0

Some pull ideas:
=A0- poll a file on a shared drive
Is this depe= nds on the OS level sharing=A0 ?
=A0- poll a url, basic txt webpage
This depends= on a web server.
=A0- poll a db (yuck)
yuck : )
=
=A0- poll a service (rest, rmi, jms)
Some push ideas:
=A0- RMI service on node
=A0- REST or HTTP service on node
=A0- JMS (sort of both push and pull)

Jms w= ill require brokers, Maybe RMI is a plausible solution.=A0

How would rest be implemented here ?


-David





--
Shawn



--
Shawn
--000e0cd117689ca5a4047e818970--