geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [clustering] kinds of clustering was (Re: [jndi] Have we found a JNDI impl yet?)
Date Mon, 08 Sep 2003 13:16:38 GMT

On Friday, August 29, 2003, at 05:07  pm, Bruce Snyder wrote:

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

I've already exchanged lots of mail with Bela on this subject. As a 
result a few of us including Bela are putting together a BSD licensed 
API for JavaGroups which would allow us to abstract away a little of 
JavaGroups specific implementation details and allow any implementation 
to be plugged in at runtime - such as a JMS implementation - or the 
current JavaGroups distribution.

IIRC there's gonna be a new project hosted at for this API any 
day now - I'll mail again with the details when I have them.


View raw message