geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Pulling Geronimo Configuration
Date Wed, 11 Feb 2009 22:46:35 GMT

On Feb 11, 2009, at 1:13 PM, Gianny Damour wrote:

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

I think it would be great to get node discovery based on WADI  
working.  Unfortunately I was in too much of a hurry when I  
implemented the plugin based farming to look into how to do this.

Where is your ejb client failover code?

thanks
david jencks

>
>
> Thanks,
> Gianny
>
>
>> Thanks for your help,
>>
>> Chance
>>


Mime
View raw message