[clustering] kinds of clustering was (Re: [jndi] Have we found a JNDI impl yet?)

[James Strachan <ja...@yahoo.co.uk>]

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

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

James
-------
http://radio.weblogs.com/0112098/

Re: [clustering] kinds of clustering was (Re: [jndi] Have we found a JNDI impl yet?)

[James Strachan <ja...@yahoo.co.uk>]

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 java.net for this API any 
day now - I'll mail again with the details when I have them.

James
-------
http://radio.weblogs.com/0112098/

Re: [clustering] kinds of clustering was (Re: [jndi] Have we found a JNDI impl yet?)

[Bruce Snyder <fe...@frii.com>]

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