geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: Pulling Geronimo Configuration
Date Wed, 11 Feb 2009 21:13:40 GMT
On 12/02/2009, at 6:08 AM, Chance Yeoman wrote:

> On Feb 11, 2009, at 9:32 AM, Chance Yeoman wrote:
>> Thank you for information,
>> My understanding of the plugin-based farming is incomplete as well.
>> From the Geronimo 2.1 documentation of plugin-based farming, it did
>> not seem as if node server configuration was checked and updated
>> upon startup.  Is this new to Geronimo 2.2 farming?
> I think the plugin based farming is only in 2.2.  IIRC the deployment
> based farming in 2.1 relies on pushing stuff.
>> As an alternative to multicast, our configuration could use a
>> configured admin server approach to node discovery by using a
>> virtual IP that would route to a master server.  Unlike
>> multicasting, this approach would require configuration external to
>> Geronimo to remain flexible, like virtual IP routing or DNS
>> management.  While multicast would be a better choice for most
>> configurations, would it be plausible to include admin server
>> hostname/IP based node discovery as a configuration option, with
>> multicast as the default?
> That sounds reasonable to me, although I don't know how virtual IP
> works.
> Since we're talking about a new feature it would be better to move the
> discussion to the dev list, and if you would open a jira that would
> also help.
> Depending on your requirements I can think of a couple of possible
> strategies:
> 1. when a node starts up it request the plugin list from the admin
> server.  In this case the admin server doesn't track the node members
> and if you update a plugin list nodes won't know until they restart.
> 2. when a node starts up it starts pinging the admin server.  The
> admin server tracks cluster members similarly to how it does now with
> multicast.  Changes to plugin lists will be propagated quickly to
> running nodes.
> I think (2) would be easier to implement as it just replaces the
> multicast heartbeat with a more configured one.
> Would you be interested in contributing an implementation?
> thanks
> david jencks
> Absolutely.  I'm taking a peek at the MulticastDiscoveryAgent code  
> to get an idea of how a new implementation would plug in.
> I agree that strategy 2 would be a good place to start as the  
> behavior of the server farm would be the same regardless of the  
> node discovery mechanism.
> One requirement that this would not address is the ability to  
> rotate plugin deployments to cluster member nodes one at a time or  
> in separate batches rather than all at once.  This functionality  
> would probably belong elsewhere though.
> I will open a jira about optionally configuring an admin host for  
> node discovery and begin work on an implementation.


FWIW, WADI provides API to implement this kind of tracking and  
trigger remote services.  A ServiceSpace can be executed on each note 

. When a node joins or stops, you can receive events by registering a  

If you are interested by a specific remote service running on a node,  
e.g. a service tracking the plugins installed on the admin server,  
then you can also receive events all along its lifecycle by  
registering a ServiceListener 

To invoke a remote service, e.g. to retrieve all the plugins  
installed on the admin server, you can dynamically create a service  
proxy by using a ServiceProxyFactory (more info there http:// 

This is the approach I used to track the location of specific  
stateful SessionBean types to support the fail-over of EJB clients.  
This is also the approach I used to implement the WADI admin console  
which can track where sessions are located and gather various  

If you want to implement from scratch a node discovery feature, then  
I believe that capturing the key contracts as part of the geronimo- 
clustering project would be great (which has support for the tracking  
of cluster member).


> Thanks for your help,
> Chance

View raw message