Re: Dublin - Clustering get-together.... - Report
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. **/
Re: Dublin - Clustering get-together.... - Report
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
Re: Dublin - Clustering get-together.... - Report...
Guys, They are taking down the network here in the next 5 mins or so and I am only half way through the write up - so I am going to ask you all to bear with me until I get home tomorrow. Sorry to keep you all waiting, Jules Jules Gosnell wrote: It looks like I am going to make it to Dublin afterall. I think this will be a good chance for anyone interested in Geronimo clustering to get together and talk about scope, architecture, resourcing, roadmap etc - in short, anything that we need to get the beast rolled out. Here is a link to a clustering architecture overview that I put together some time ago - it's a little out of date. It doesn't mention Lingo, which should be very useful for cluster management, the proposed Session API or recent developments with geronimo-cache etc... but it is a good starting point to demostrate the direction that I am coming from. http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Clustering Covalent have kindly offered to host the meeting - its just up to us to provide some content and some people :-) Everyone with an interest in clustering is welcome. It will be very informal, structure depending largely on who turns up. If you would like to come, we need to know ASAP so that we can find a window that will fit with the majority of your time constraints, so, please join the thread and let us know. We are thinking of some time thursday afternoon or evening. If you cannot make a slot during this window, please mention it. looking forward to seeing you all there, Jules
