Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <47393951.1070602@apache.org>
References: <B7ACC817-A9F6-4488-B4D8-16790A8BABC6@optusnet.com.au>
 <47388ED9.7050000@apache.org>
 <5F7BA842-86D1-4EE1-864E-C32D02FF1A1F@optusnet.com.au>
 <47393951.1070602@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DDF9F362-4900-4F9D-9D08-7F9266E0520F@optusnet.com.au>
Content-Transfer-Encoding: 7bit
From: Gianny Damour <gianny.damour@optusnet.com.au>
Subject: Re: Distribution and start/stop of clustered deployments
Date: Tue, 13 Nov 2007 18:47:31 +1100
To: dev@geronimo.apache.org


On 13/11/2007, at 4:42 PM, Jeff Genender wrote:

> Gianny Damour wrote:
>> You can successfully "distribute" when all the configured cluster
>> members are running. If one of them is down, then the installation
>> fails. This seems to be a typical scenario - at least based on the
>> clustered deployments I have been working with.
>
> Hmmm...I have found this to be different...
>
> I have found that if 1 node in the cluster is bad, it is removed from
> the general cluster array (i.e. look at heartbeats and the
> joining/leaving of a general cluster).
>
> This is a valid use case.  The 1 server could have a problem with
> it...such as network, hardware, etc.  Not clustering due to a bad  
> server
> would defeat the purpose of providing for fail over.

I hope we are not talking about the same thing. I am talking about a  
"deployment time" constraint and not a "runtime" constraint mandating  
that all the servers are reachable when an application is *deployed*.  
FWIW, such a constraint was also defined by WebLogic 7.0; from  
WebLogic 8.x+, this constraint was subsequently relaxed in order to  
allow the deployment to a sub-set of the cluster members - however,  
users can still enforce it if they want and partial deployments is  
not recommended. As previously said, it is trivial to implement a  
GBean to distribute a backed configuration to a server, which was not  
reachable upon deployment.

Thanks,
Gianny


>
>> Hence this is the
>> simplest implementation possible for this initial stab of clustered
>> deployment. Furthermore, as I explained in my email, there is a  
>> carbon
>> copy of the already backed configuration within the master-repository
>> and it is trivial to: either improve the GBean in charge of the  
>> remote
>> control of configurations; or to add new GBeans in order to
>> automatically upload this carbon copy to cluster members which  
>> were not
>> running upon installation.
>>
>> Also, you still need to honor my request for heads-up :). If you are
>> working on clustering, then could you please provide some headlines?
>>
>
> I am working on the EJB clustering and hope that we can both  
> communicate
> on the list when we are committing in this area.
>
> Jeff
>