You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Kevan Miller <ke...@gmail.com> on 2010/01/20 00:15:29 UTC
failover demo in sandbox
I took a look at the failover demo currently in sandbox, over the weekend. I made some updates to get it building/running on my Mac OS machine.
I like the demo. It's a good demonstration of Geronimo's capabilities. I'd be interested in seeing a formal release of the demo. A few demo and Geronimo related issues we could be thinking about:
1) Windows support. The current demo is *nix-based. For all I know it may only run on Mac OS.
2) The failover demo is including Grinder. Grinder is a great tool. However, it contains LGPL-licensed artifacts. So, we are going to remove it from the failover demo. We can provide configuration files and the grinder.py "client". However, if users want to run the demo using Grinder, they will need to download Grinder on their own. We can provide download instructions, but should instruct users to review the Grinder licensing before doing so...
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.
--kevan
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
On Wed, Jan 20, 2010 at 4:14 PM, Shawn Jiang <ge...@gmail.com> wrote:
> I think there should be a failover example with finer granularity. Just
> like what we did
>
>
>
> On Wed, Jan 20, 2010 at 7:15 AM, Kevan Miller <ke...@gmail.com>wrote:
>
>> I took a look at the failover demo currently in sandbox, over the weekend.
>> I made some updates to get it building/running on my Mac OS machine.
>>
>> I like the demo. It's a good demonstration of Geronimo's capabilities. I'd
>> be interested in seeing a formal release of the demo. A few demo and
>> Geronimo related issues we could be thinking about:
>>
>> 1) Windows support. The current demo is *nix-based. For all I know it may
>> only run on Mac OS.
>>
>> 2) The failover demo is including Grinder. Grinder is a great tool.
>> However, it contains LGPL-licensed artifacts. So, we are going to remove it
>> from the failover demo. We can provide configuration files and the
>> grinder.py "client". However, if users want to run the demo using Grinder,
>> they will need to download Grinder on their own. We can provide download
>> instructions, but should instruct users to review the Grinder licensing
>> before doing so...
>>
>> 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.
>>
>
>
> If you are referring Web level cluserting. G2.2 supports unicast-based
> failover already. see "Creating a Static Wadi Configuration" section of
> [1]. I agree that we need to also support unicast-based support for
> Clustering of SFSB.
>
> [1]http://cwiki.apache.org/GMOxDOC22/wadi-clustering.html
>
> PS: Clustering of SFSB is mentioned in [1] also, Is it correct ? IIUC,
> the failover of SFSB in openEJB has no relationship with WADI at all.
>
OK, IIUC. OpenEJB use multicast to support failover for session bean but
without session replication for stateful session bean. Geronimo utilize
WADI to add a session replication for Stateful session bean so that Geronimo
support failover for both stateless and stateful session bean.
I think we should have more example and document for EJB failover including:
1, Stateless session bean failover example. (this should not need WADI)
2, Stateful session bean failover example. (this should include WADI
configuration.)
Both of the topics above should be be seperated from [1]. And [1] should
focus on the Web level WADI clustering configuration only.
[1]http://cwiki.apache.org/GMOxDOC22/wadi-clustering.html
>
>
>>
>> --kevan
>
>
>
>
> --
> Shawn
>
--
Shawn
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
I think there should be a failover example with finer granularity. Just
like what we did
On Wed, Jan 20, 2010 at 7:15 AM, Kevan Miller <ke...@gmail.com>wrote:
> I took a look at the failover demo currently in sandbox, over the weekend.
> I made some updates to get it building/running on my Mac OS machine.
>
> I like the demo. It's a good demonstration of Geronimo's capabilities. I'd
> be interested in seeing a formal release of the demo. A few demo and
> Geronimo related issues we could be thinking about:
>
> 1) Windows support. The current demo is *nix-based. For all I know it may
> only run on Mac OS.
>
> 2) The failover demo is including Grinder. Grinder is a great tool.
> However, it contains LGPL-licensed artifacts. So, we are going to remove it
> from the failover demo. We can provide configuration files and the
> grinder.py "client". However, if users want to run the demo using Grinder,
> they will need to download Grinder on their own. We can provide download
> instructions, but should instruct users to review the Grinder licensing
> before doing so...
>
> 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.
>
If you are referring Web level cluserting. G2.2 supports unicast-based
failover already. see "Creating a Static Wadi Configuration" section of
[1]. I agree that we need to also support unicast-based support for
Clustering of SFSB.
[1]http://cwiki.apache.org/GMOxDOC22/wadi-clustering.html
PS: Clustering of SFSB is mentioned in [1] also, Is it correct ? IIUC, the
failover of SFSB in openEJB has no relationship with WADI at all.
>
> --kevan
--
Shawn
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
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 <ge...@gmail.com> wrote:
>
>
> On Thu, Jan 28, 2010 at 8:20 AM, David Blevins <da...@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
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
On Thu, Jan 28, 2010 at 8:20 AM, David Blevins <da...@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
Re: failover demo in sandbox
Posted by David Blevins <da...@visi.com>.
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
Re: failover demo in sandbox
Posted by Kevan Miller <ke...@gmail.com>.
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...
--kevan
Re: failover demo in sandbox
Posted by David Blevins <da...@visi.com>.
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 ?).
-David
Re: failover demo in sandbox
Posted by David Blevins <da...@visi.com>.
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.
-David
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
Added unicast slsb failover support with
https://issues.apache.org/jira/browse/GERONIMO-5059?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel
The OpenEJB client is working well because it supports the clustering
failover with PROVIDER_URL "*ejbd://192.168.1.2:4221*" if the target
container is cluster enabled.
I'll update or create a new failover example for this. I'll also create
another JIRA to enable the unicast plugin farming.
On Tue, Feb 23, 2010 at 5:53 PM, Shawn Jiang <ge...@gmail.com> wrote:
> I've implemented a WADIdiscoveryAgent. This agent can be either multicast
> or unicast based on geronimo WADI clustering setting. The underlying
> transportation mechanism are transparent to the agent user.
>
> The WADIdiscoveryAgent based Farming plugin is working well now. I'm
> trying to test the stateless ejb. current failover example client are still
> based on multicast agent.
>
> p[Context.INITIAL_CONTEXT_FACTORY] =
> "org.apache.openejb.client.RemoteInitialContextFactory"
> p[Context.PROVIDER_URL] = "*multicast*://239.255.3.2:6142?group=cluster1";
> InitialContext(p)
>
> I'm wondering if there's a way like following to specify a static unicast
> node address in OpenEJB client code ?
>
> p[Context.INITIAL_CONTEXT_FACTORY] =
> "org.apache.openejb.client.RemoteInitialContextFactory"
> p[Context.PROVIDER_URL] = "*ejbd://192.168.1.2:4221*?group=cluster1 , *
> ejbd://10.2.1.2:4221*?group=cluster1, *ejbd://192.168.1.2:4221*
> ?group=cluster1";
> InitialContext(p)
>
>
>
> On Wed, Feb 3, 2010 at 6:23 PM, David Blevins <da...@visi.com>wrote:
>
>>
>> On Feb 3, 2010, at 9:57 AM, Shawn Jiang wrote:
>>
>> There are some discussions before that we should use WADI instead of
>>> discoveryAgent to track cluster nodes.
>>>
>>>
>>> http://old.nabble.com/Re%3A-Pulling-Geronimo-Configuration-td21962048s134.html
>>>
>>> I would like to give it a try instead of implementing another discovery
>>> agent.
>>>
>>
>> A WADI implementation of the DiscoveryAgent interface might work. If it
>> is able to keep a server list and notify people when items are added and
>> removed, then it would work fine.
>>
>> If you mean to remove the DiscoveryAgent abstraction and rewrite the
>> related Geronimo and OpenEJB code that uses it, then that is something we'd
>> probably want to avoid. Would probably be better to "fix" the abstraction
>> if there was something wrong with it. It is pretty simple though. Whoever
>> maintains the big list of all services simply needs to call the
>> DiscoveryListener's "add" or "remove" methods so that parts of the system
>> who are interested can act accordingly.
>>
>>
>> -David
>>
>>
>
>
> --
> Shawn
>
--
Shawn
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
I've implemented a WADIdiscoveryAgent. This agent can be either multicast
or unicast based on geronimo WADI clustering setting. The underlying
transportation mechanism are transparent to the agent user.
The WADIdiscoveryAgent based Farming plugin is working well now. I'm
trying to test the stateless ejb. current failover example client are still
based on multicast agent.
p[Context.INITIAL_CONTEXT_FACTORY] =
"org.apache.openejb.client.RemoteInitialContextFactory"
p[Context.PROVIDER_URL] = "*multicast*://239.255.3.2:6142?group=cluster1";
InitialContext(p)
I'm wondering if there's a way like following to specify a static unicast
node address in OpenEJB client code ?
p[Context.INITIAL_CONTEXT_FACTORY] =
"org.apache.openejb.client.RemoteInitialContextFactory"
p[Context.PROVIDER_URL] = "*ejbd://192.168.1.2:4221*?group=cluster1 , *
ejbd://10.2.1.2:4221*?group=cluster1, *ejbd://192.168.1.2:4221*
?group=cluster1";
InitialContext(p)
On Wed, Feb 3, 2010 at 6:23 PM, David Blevins <da...@visi.com>wrote:
>
> On Feb 3, 2010, at 9:57 AM, Shawn Jiang wrote:
>
> There are some discussions before that we should use WADI instead of
>> discoveryAgent to track cluster nodes.
>>
>>
>> http://old.nabble.com/Re%3A-Pulling-Geronimo-Configuration-td21962048s134.html
>>
>> I would like to give it a try instead of implementing another discovery
>> agent.
>>
>
> A WADI implementation of the DiscoveryAgent interface might work. If it is
> able to keep a server list and notify people when items are added and
> removed, then it would work fine.
>
> If you mean to remove the DiscoveryAgent abstraction and rewrite the
> related Geronimo and OpenEJB code that uses it, then that is something we'd
> probably want to avoid. Would probably be better to "fix" the abstraction
> if there was something wrong with it. It is pretty simple though. Whoever
> maintains the big list of all services simply needs to call the
> DiscoveryListener's "add" or "remove" methods so that parts of the system
> who are interested can act accordingly.
>
>
> -David
>
>
--
Shawn
Re: failover demo in sandbox
Posted by David Blevins <da...@visi.com>.
On Feb 3, 2010, at 9:57 AM, Shawn Jiang wrote:
> There are some discussions before that we should use WADI instead of
> discoveryAgent to track cluster nodes.
>
> http://old.nabble.com/Re%3A-Pulling-Geronimo-Configuration-td21962048s134.html
>
> I would like to give it a try instead of implementing another
> discovery agent.
A WADI implementation of the DiscoveryAgent interface might work. If
it is able to keep a server list and notify people when items are
added and removed, then it would work fine.
If you mean to remove the DiscoveryAgent abstraction and rewrite the
related Geronimo and OpenEJB code that uses it, then that is something
we'd probably want to avoid. Would probably be better to "fix" the
abstraction if there was something wrong with it. It is pretty simple
though. Whoever maintains the big list of all services simply needs
to call the DiscoveryListener's "add" or "remove" methods so that
parts of the system who are interested can act accordingly.
-David
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
On Fri, Jan 22, 2010 at 2:49 AM, David Blevins <da...@visi.com>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.
>
There are some discussions before that we should use WADI instead of
discoveryAgent to track cluster nodes.
http://old.nabble.com/Re%3A-Pulling-Geronimo-Configuration-td21962048s134.html
I would like to give it a try instead of implementing another discovery
agent.
>
> -David
>
>
--
Shawn
Re: failover demo in sandbox
Posted by David Blevins <da...@visi.com>.
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.
-David
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
On Wed, Feb 3, 2010 at 2:51 AM, Kevan Miller <ke...@gmail.com> wrote:
>
> On Feb 1, 2010, at 1:59 AM, Shawn Jiang wrote:
>
>
>
> On Wed, Jan 20, 2010 at 7:15 AM, Kevan Miller <ke...@gmail.com>wrote:
>
>> I took a look at the failover demo currently in sandbox, over the weekend.
>> I made some updates to get it building/running on my Mac OS machine.
>>
>> I like the demo. It's a good demonstration of Geronimo's capabilities. I'd
>> be interested in seeing a formal release of the demo. A few demo and
>> Geronimo related issues we could be thinking about:
>>
>> 1) Windows support. The current demo is *nix-based. For all I know it may
>> only run on Mac OS.
>>
>
> Added windows scripts to make the sample support windows.
>
>>
>> 2) The failover demo is including Grinder. Grinder is a great tool.
>> However, it contains LGPL-licensed artifacts. So, we are going to remove it
>> from the failover demo. We can provide configuration files and the
>> grinder.py "client". However, if users want to run the demo using Grinder,
>> they will need to download Grinder on their own. We can provide download
>> instructions, but should instruct users to review the Grinder licensing
>> before doing so...
>>
>
> Modified/added some scripts to strip grinder from our build. Also updated
> the instruction to tell users how to download and configure the grinder by
> themselves.
>
>
>>
>> 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.
>
>
>> --kevan
>
>
> Nice. Thanks Shawn.
>
> I think it's time to move failover out of sandbox.
>
> BTW,
> I've noticed that the farm-controller is advertising membership in cluster1
> -- leading to intermittent lookup failures. Using the MulticastTool:
>
> $ java org.apache.openejb.client.MulticastTool
>
> Connecting to multicast group: 239.255.3.2:6142
> LoopbackMode:false
> TimeToLive:1
> SoTimeout:0
> -------------------------------
> 12:56:03 - 10.0.1.194 - cluster1:ejb:ejbd://coltrane:4201
> 12:56:03 - 10.0.1.194 -
> farm:rmi://coltrane:1109/JMXConnector?cluster=cluster1
> 12:56:03 - 10.0.1.194 - cluster1:ejb:ejbd://coltrane:4211
> 12:56:03 - 10.0.1.194 - cluster1:ejb:ejbd://coltrane:4201
> 12:56:03 - 10.0.1.194 -
> farm:rmi://coltrane:1109/JMXConnector?cluster=cluster1
>
> 4201 == my farm-controller
> 4211 == my farm-node
>
> I'll get intermittent failures using multicast as the provider url in a
> standalone client -- depending on which member is chosen by the client --
> ejbd://coltrane:4201 will fail and ejbd://coltrane:4211 will succeed.
>
I also found this issue, but I don't get failures when using the ginder
client to access the cluster including controller as a node.
I guess the controller's farm clustering name should be rename to something
else than the default cluster1. So that it can be filtered by the cluster1
in provider url.
>
> --kevan
>
--
Shawn
Re: failover demo in sandbox
Posted by Kevan Miller <ke...@gmail.com>.
On Feb 1, 2010, at 1:59 AM, Shawn Jiang wrote:
>
>
> On Wed, Jan 20, 2010 at 7:15 AM, Kevan Miller <ke...@gmail.com> wrote:
> I took a look at the failover demo currently in sandbox, over the weekend. I made some updates to get it building/running on my Mac OS machine.
>
> I like the demo. It's a good demonstration of Geronimo's capabilities. I'd be interested in seeing a formal release of the demo. A few demo and Geronimo related issues we could be thinking about:
>
> 1) Windows support. The current demo is *nix-based. For all I know it may only run on Mac OS.
>
> Added windows scripts to make the sample support windows.
>
> 2) The failover demo is including Grinder. Grinder is a great tool. However, it contains LGPL-licensed artifacts. So, we are going to remove it from the failover demo. We can provide configuration files and the grinder.py "client". However, if users want to run the demo using Grinder, they will need to download Grinder on their own. We can provide download instructions, but should instruct users to review the Grinder licensing before doing so...
>
> Modified/added some scripts to strip grinder from our build. Also updated the instruction to tell users how to download and configure the grinder by themselves.
>
>
> 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.
>
> --kevan
Nice. Thanks Shawn.
I think it's time to move failover out of sandbox.
BTW,
I've noticed that the farm-controller is advertising membership in cluster1 -- leading to intermittent lookup failures. Using the MulticastTool:
$ java org.apache.openejb.client.MulticastTool
Connecting to multicast group: 239.255.3.2:6142
LoopbackMode:false
TimeToLive:1
SoTimeout:0
-------------------------------
12:56:03 - 10.0.1.194 - cluster1:ejb:ejbd://coltrane:4201
12:56:03 - 10.0.1.194 - farm:rmi://coltrane:1109/JMXConnector?cluster=cluster1
12:56:03 - 10.0.1.194 - cluster1:ejb:ejbd://coltrane:4211
12:56:03 - 10.0.1.194 - cluster1:ejb:ejbd://coltrane:4201
12:56:03 - 10.0.1.194 - farm:rmi://coltrane:1109/JMXConnector?cluster=cluster1
4201 == my farm-controller
4211 == my farm-node
I'll get intermittent failures using multicast as the provider url in a standalone client -- depending on which member is chosen by the client -- ejbd://coltrane:4201 will fail and ejbd://coltrane:4211 will succeed.
--kevan
Re: failover demo in sandbox
Posted by Shawn Jiang <ge...@gmail.com>.
On Wed, Jan 20, 2010 at 7:15 AM, Kevan Miller <ke...@gmail.com>wrote:
> I took a look at the failover demo currently in sandbox, over the weekend.
> I made some updates to get it building/running on my Mac OS machine.
>
> I like the demo. It's a good demonstration of Geronimo's capabilities. I'd
> be interested in seeing a formal release of the demo. A few demo and
> Geronimo related issues we could be thinking about:
>
> 1) Windows support. The current demo is *nix-based. For all I know it may
> only run on Mac OS.
>
Added windows scripts to make the sample support windows.
>
> 2) The failover demo is including Grinder. Grinder is a great tool.
> However, it contains LGPL-licensed artifacts. So, we are going to remove it
> from the failover demo. We can provide configuration files and the
> grinder.py "client". However, if users want to run the demo using Grinder,
> they will need to download Grinder on their own. We can provide download
> instructions, but should instruct users to review the Grinder licensing
> before doing so...
>
Modified/added some scripts to strip grinder from our build. Also updated
the instruction to tell users how to download and configure the grinder by
themselves.
>
> 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.
> --kevan
--
Shawn