Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Fri, 29 Aug 2003 16:07:03 +0000 (GMT)
From: Bruce Snyder <ferret@frii.com>
To: geronimo-dev@incubator.apache.org
Subject: Re: [clustering] kinds of clustering was (Re: [jndi] Have we found
 a JNDI impl yet?)
In-Reply-To: <F3FEF2EB-DA1C-11D7-8FD9-000A959D0312@yahoo.co.uk>
Message-ID: 
 <Pine.LNX.4.44.0308291555140.6572-100000@pclnxbsnyder.digitalglobe.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This one time, at band camp, James Strachan said:

Please see my comments inline. 

JS>On Friday, August 29, 2003, at 01:16  pm, Alex Blewitt wrote:
JS>
JS>> On Friday, Aug 29, 2003, at 12:59 Europe/London, Daniel S. Haischt 
JS>> wrote:
JS>>
JS>>> Alex Blewitt wrote:
JS>>>
JS>>> [...]
JS>>>
JS>>>> You also have to consider the case when a clustered system is in 
JS>>>> operation. Then, they are likely to need to share data that is 
JS>>>> installed, and a sensible back-end may need to synchronize such 
JS>>>> writes across a number of nodes/clusters.
JS>>>> I agree for a single-server environment, having an in-memory cache 
JS>>>> will be the fastest, but having a switchable JNDI server will allow 
JS>>>> both :-)
JS>>>
JS>>> is there already someone working on a clustering solution?
JS>>>
JS>>> sometimes i am wondering whether we are aiming to provide a all-in-one
JS>>> wonder. wouldn't it be possible to start with a more simple in-memory
JS>>> solution and switch to a more complex solution while Geronimo emerges?
JS>>
JS>> Geronimo is currently a single-node system. It would obviously be 
JS>> desirable to support clustering at a later stage.
JS>>
JS>> However, thinking about the aspects involved in clustering now, it 
JS>> allows us to make better abstractions which will allow us to migrate 
JS>> to a clustered solution easier in the future.
JS>
JS>There are many forms of clustering. Off the top of my head this 
JS>includes...
JS>
JS>* JNDI clustering (either peer based or LDAP style master-slave model)
JS>* clustered caching (a big topic in and of itself) used for all kinds 
JS>of things from arbitrary application data to CMP / JDO caching
JS>* clustered HTTP / session bean state (similar in some ways to the 
JS>above with some differences - typically sticky-ness)
JS>* clustered servers - e.g. deploying a WAR / EAR to the cluster & it 
JS>runs everywhere in the cluster etc
JS>* clustered JMS implementation (using clustering for persistence for HA 
JS>to avoid message loss)

* HA services (failover and load balancing) 
* automatic instance discovery 
* easy management of the entire cluster (this gets into netboot and other
  monitoring functionality)

JS>I'd hope we can implement them all in some modular & configurable way 
JS>so users are free to pay whatever cost (in RAM, I/O, CPU, complexity or 
JS>whatever) they are happy with to get the quality of service they need 
JS>in all aspects of Geronimo.

We definiely need to consider building a decoupled layer allowing
differnet solutions to be plugged in. The first solution that comes
to my mind is JavaGroups (soon to be renamed JGroups), because of
it's capabilities. It's designed to provide exactly this type of
functionality. The problem with JGroups is that it is licensed using
the LGPL. Maybe I could ask Bela about a dual licensing strategy. I was
planning on talking to him soon anyway.

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

The Castor Project 
http://www.castor.org/

Apache Geronimo 
http://incubator.apache.org/projects/geronimo.html