Thanks, Greg,
The more views on what was actually discussed and decided the better.
I hope to have some constructive thoughts on the session API and a
propsed clustering API shortly - time allowing.
Jules
Greg Wilkins wrote:
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
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
