geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject [clustering] kinds of clustering was (Re: [jndi] Have we found a JNDI impl yet?)
Date Fri, 29 Aug 2003 12:33:11 GMT

On Friday, August 29, 2003, at 01:16  pm, Alex Blewitt wrote:

> On Friday, Aug 29, 2003, at 12:59 Europe/London, Daniel S. Haischt 
> wrote:
>> Alex Blewitt wrote:
>> [...]
>>> You also have to consider the case when a clustered system is in 
>>> operation. Then, they are likely to need to share data that is 
>>> installed, and a sensible back-end may need to synchronize such 
>>> writes across a number of nodes/clusters.
>>> I agree for a single-server environment, having an in-memory cache 
>>> will be the fastest, but having a switchable JNDI server will allow 
>>> both :-)
>> is there already someone working on a clustering solution?
>> sometimes i am wondering whether we are aiming to provide a all-in-one
>> wonder. wouldn't it be possible to start with a more simple in-memory
>> solution and switch to a more complex solution while Geronimo emerges?
> Geronimo is currently a single-node system. It would obviously be 
> desirable to support clustering at a later stage.
> However, thinking about the aspects involved in clustering now, it 
> allows us to make better abstractions which will allow us to migrate 
> to a clustered solution easier in the future.

There are many forms of clustering. Off the top of my head this 

* JNDI clustering (either peer based or LDAP style master-slave model)
* clustered caching (a big topic in and of itself) used for all kinds 
of things from arbitrary application data to CMP / JDO caching
* clustered HTTP / session bean state (similar in some ways to the 
above with some differences - typically sticky-ness)
* clustered servers - e.g. deploying a WAR / EAR to the cluster & it 
runs everywhere in the cluster etc
* clustered JMS implementation (using clustering for persistence for HA 
to avoid message loss)

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


View raw message