geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: Dublin - Clustering get-together.... - Report
Date Wed, 05 Jul 2006 07:33:15 GMT

All,

I am going to give my own short report on the meeting.  I'm not 
intending to decent from Jules report - simply to give a short version 
that highlights the important issues (for me).


We covered lots of clustering requirements and issues - made us all 
realize how big and challenging a complete clustering solution is.  
There are few easy wins here.

Views on what we are aiming for ranged from "we need world class solution 
for all aspects of clustering" to "we need something that works for the
tick box aspects ASAP".  Many thought both. 

A pluggable API approach to allow multiple implementations was widely 
accepted as the best way to go.

The session API is the current focus for putting clustering in G.  
Some do not think it should be... but for better or worse it is.

Views on the current session API ranged from: "it is pretty good for 
the job." through "it is the best we can expect to do" and "it is 
adequate for what it is, but we need more"  to "it is totally 
unsatisfactory".

It was apparent that it was difficult to discuss other aspects
of clustering (eg management/configuration) with out the conversation 
returning to the suitability or otherwise of the session API.

Matt floated the idea that in order to move on, we have a period of review on
the session API (which we time box).   Critics of the API have the next few
weeks to make the case to either extend, re factor or replace this API, 
after which we should try to push through to working implementations (with 
the normal amount of agile refactoring etc.).

This was accepted as the key outcome of the meeting.



Some secondary points:

We frequently blurred and then clarified the somewhat conflicting requirements
for clustering for availability and clustering for scalability.  It is very
easy to miss communicate when talking clustering!

It was pointed out that even with a G clustering API, we will have to work
within the limitations of the implementations that we plug into it and we
cannot dictate G implementations of things like heartbeats and cluster
discovery.  The counter point to this was that it would be good that if 
an implementation we could use a standard API to extract cluster meta data
from an implementation that did do heartbeats and discover, for reuse by
one that did not (eg JNDI impl could get it's list of known nodes from the
HTTP session impl). 


cheers


Mime
View raw message