geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
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.
>
>

Hi,

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

http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ 
servicespace/ServiceSpace.html

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

http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ 
servicespace/ServiceSpaceListener.html

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

http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ 
servicespace/ServiceListener.html

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:// 
docs.codehaus.org/display/WADI/2.+Distributed+Services)

http://wadi.codehaus.org/wadi-core/xref/org/codehaus/wadi/ 
servicespace/ServiceProxyFactory.html


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  
statistics.

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,
Gianny


> Thanks for your help,
>
> Chance
>

Mime
View raw message