Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 15519 invoked from network); 12 Jan 2006 11:52:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Jan 2006 11:52:48 -0000 Received: (qmail 13883 invoked by uid 500); 12 Jan 2006 11:52:47 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 13177 invoked by uid 500); 12 Jan 2006 11:52:43 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 13154 invoked by uid 99); 12 Jan 2006 11:52:43 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jan 2006 03:52:43 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [209.235.255.182] (HELO jetty3.inetu.net) (209.235.255.182) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jan 2006 03:52:41 -0800 Received: (qmail 80331 invoked from network); 12 Jan 2006 11:52:19 -0000 Received: from host86-134-127-194.range86-134.btcentralplus.com (HELO ?192.168.0.4?) (jules@86.134.127.194) by jetty3.inetu.net with AES256-SHA encrypted SMTP; 12 Jan 2006 11:52:19 -0000 Message-ID: <43C642CD.6020702@coredevelopers.net> Date: Thu, 12 Jan 2006 11:51:41 +0000 From: Jules Gosnell User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: [wadi-dev] Re: [Geronimo] Clustering References: <43BE5F0B.6040709@coredevelopers.net> <43BE8654.2050204@hogstrom.org> <43BE9B4C.5050600@coredevelopers.net> <43C62D0B.50408@coredevelopers.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Ryan Thomas wrote: > Hey guys, > > I'm really interested in the clustering side of geronimo, I'm just > checking the source out of subversion now (on dialup until saturday - > so it's a slow process). > > Any tips on where to start looking in the source? It's currently scattered around a number of external and incubated projects. Which areas interest you the most - web, ejb, jndi, deployment, management/monitoring, pojo... ? Let us know and I will hook you up :-) Jules > > Cheers, > > -Ryan > > On 1/12/06, *Jules Gosnell* > wrote: > > Jules Gosnell wrote: > > > Matt Hogstrom wrote: > > > >> Jules, I think you are spot on with a summary at this point. At > >> least in my conversations a person's view of clustering is > influenced > >> by which aspect of clustering they are intersted in. I think a > short > >> doc would be really helpful here. Were you planning on doing > that or > >> would you like some help? > > > > > > Matt, > > > > The more I look at the amount of work that needs doing the more > help I > > think I need ! > > > > I am away this weekend, but I will try to put together a document > > skeleton early next week that defines the areas that we need to > cover. > > Then we can refer back to various discussions on the list to > flesh out > > the relevant areas. I'm not sure of the best way of making this > > document available so that everyone can contribute - but we can > worry > > about that when we have one. > > > > Do you have a pet clustering area ? Have we discussed it ? > > > > Jules > > > Guys, > > I am on this - just have had a very busy week. I'll get back to > the list > with the goods ASAP. > > Jules > > >> > >> Jules Gosnell wrote: > >> > >>> Rajith Attapattu wrote: > >>> > >>>> Hmm, again we have stopped the discussion :). Lets get it > started > >>>> again. > >>> > >>> > >>> > >>> > >>> OK - I will pick it up. I've been a bit preoccupied with WADI > for a > >>> while, so apologies for letting this one go cold. > >>> > >>>> > >>>> So can we all come to some agreement (with more discussion) on > >>>> which direction we might be taking !! > >>>> > >>>> Like merging ActiveCluster and WADI or getting best of both > worlds ? > >>> > >>> > >>> > >>> > >>> hmmm... > >>> > >>> not sure I follow you here... > >>> > >>> are you suggesting merging them because you view them as (a) > >>> competing or (b) complimentary technologies ? > >>> > >>> If (a), then I need to put you straight. WADI is a technology that > >>> builds on top of ActiveCluster (AC). AC provides basic clustering > >>> fn-ality (most importantly, a membership abstraction along with > >>> notifications of membership change). > >>> > >>> If (b), then, whilst WADI and AC could be merged, the current > >>> separation is along clear and modular lines and I see no advantage > >>> to collapsing the two projects into one. > >>> > >>> I think that there is far more reason to consider a merger > between > >>> ActiveSpace (AS). AS is a project that also builds upon > >>> ActiveCluster to provide distributed caching fn-ality. The > >>> fundamental difference (and I stand open to correction from James > >>> here - I'm not very knowledgeable about AS) is that AS provides a > >>> host of optimistic caching strategies, whilst WADI (currently) > >>> provides a single, pessimistic strategy specifically designed for > >>> the management of state in web and ejb tiers, where the sum of the > >>> state in the tier is too great to be held by any single node. > >>> Because WADI and AC fulfil similar roles, I think that there > is more > >>> to be gained by unifying their APIs and code-sharing between them. > >>> James, if you are reading, what do you think ? > >>> > >>>> > >>>> And also if we can define expectations/requirments for what > we like > >>>> for the next possible release (1.01 or whatever) in terms of > >>>> clustering would give folks like me more direction as to where we > >>>> should concentrate on? > >>> > >>> > >>> > >>> > >>> Well, I think that there has been plenty of discussion, but > you are > >>> correct in pointing out that there is no grand unified > architecture > >>> document out there. I did start on my suggestions towards one > >>> quietly a while ago, but canned them. Perhaps enough > discussion has > >>> now occurred to put up a straw man ? Is this what you are > looking for ? > >>> > >>>> > >>>> If we decide on a direction maybe a few of us can start on a few > >>>> prototypes and see what works best for Geronimo. > >>> > >>> > >>> > >>> > >>> Rajith, judging from our conversations on this list, your interest > >>> seems to lie in JNDI clustering ? I think that we need to get > you, > >>> Gianny Damour (working on OpenEJB/WADI integration), James > Strachan > >>> (ActiveSpace) and Kresten Krab (Trifork guy involved in IIOP > stuff, > >>> which needs to be worked into equation) into a thread. > >>> > >>> OpenEJB will need cluster aware client-side proxies, delivered > from > >>> HA-JNDI. These proxies will need to talk to EJBs via OpenEJB's > >>> proprietary protocol and Trifork's IIOP impl (I'm not on my home > >>> ground here, so I might be off-base - but that is what the > thread is > >>> for). HA-JNDI needs a clustering substrate - ActiveSpace best fits > >>> the bill (JNDI will be small amounts of data that are > write-seldom > >>> and read-often). > >>> > >>> One other issue that meshes with all of this is deployment. I've > >>> given some thought to clustered deployment recently and come > to the > >>> conclusion that a deployment/app/?service? is simply a piece of > >>> write(/[un]deploy)-seldom, read(/invoke)-often data. A deployment > >>> may result in a number of entries being merged into HA-JNDI, an > >>> undeployment may result in a number being removed. If a new node > >>> joins a cluster (or subset of) that is responsible for > providing an > >>> HA-service/app, then that node should deploy an instance of > that app > >>> as it comes up and remove it as it goes down - i.e. a copy of that > >>> app should be distributed to it and maintained by it for the > >>> lifetime of the node, just as a jndi entry might be by a > distributed > >>> JNDI service. > >>> > >>> I haven't gone over these ideas with anyone else yet, particularly > >>> with regards to the relevant JSR, but I guess they need to be > thrown > >>> out into the ring and discussed. > >>> > >>> Does everyone think that now is a good time to summarise the > various > >>> discussions that have occurred about clustering into some sort of > >>> unified structure ? This can then be further discussed and > hopefully > >>> used to carve up work and produce a roadmap ? This is probably > over > >>> ambitious for a 1.0.1 release (it may just be a bug-fix > release ?), > >>> but something that we need to be getting on with. > >>> > >>> > >>> Jules > >>> > >>>> > >>>> Regards, > >>>> > >>>> Rajith Attapattu. > >>>> > >>>> > >>>> On 1/5/06, *Rajith Attapattu* > >>>> >> wrote: > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Jules Gosnell [mailto: jules@coredevelopers.net > > >>>> >] > >>>> Sent: Monday, December 19, 2005 9:55 AM > >>>> To: dev@wadi.codehaus.org > > > >>>> Cc: wadi-dev@incubator.apache.org > > >>>> >; dev@geronimo.apache.org > > >>>> > > >>>> Subject: Re: [wadi-dev] Re: [Geronimo] Clustering > >>>> > >>>> James Strachan wrote: > >>>> > >>>> > > >>>> > On 19 Dec 2005, at 14:14, Jules Gosnell wrote: > >>>> > > >>>> >> James Strachan wrote: > >>>> >> > >>>> >>> On 19 Dec 2005, at 11:53, Jules Gosnell wrote: > >>>> >>> > >>>> >>>> , whether there is other suitable Geronimo or > ASF-licensed > >>>> code > >>>> >>>> available, or whether we will need to write our own > WADI- > >>>> >>>> autodiscovery classes. The important thing is to > impose as > >>>> few > >>>> >>>> dependencies on the client as possible. The client > side code > >>>> >>>> should literally be a few lines. Clients using > clusters > >>>> should > >>>> >>>> not suddenly find themselves sucking down e.g. the > whole of > >>>> >>>> activemq, just to do a once off autodiscovery. Early > >>>> versions of > >>>> >>>> WADI had its own autodiscovery code. If we need them, > >>>> they could > >>>> >>>> be resuscitated. > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> There's no reason why you can't do a simple > implementation of > >>>> >>> ActiveCluster which doesn't use ActiveMQ - its just a > >>>> simple API. > >>>> >> > >>>> >> > >>>> >> Sure - but I'm talking about the EJB-client side - > where we > >>>> just > >>>> >> want to throw across as thin a line as possible, in > order to > >>>> haul a > >>>> >> decent strength cable back. An EJB client would not > need the > >>>> >> ActiveCluster API (I'm not thinking in terms of making EJB > >>>> clients > >>>> >> fully fledged cluster members), but simply a way of > locating > >>>> the > >>>> >> cluster and requesting a membership snapshot of it. > >>>> > > >>>> > > >>>> > Thats exactly what the ActiveCluster API is for :). > Though by > >>>> all > >>>> > means come up with another API if you can think of a > better > >>>> way of > >>>> > doing it. > >>>> > > >>>> >> This could be done by just broadcasting a query packet > at a > >>>> well > >>>> >> known multicast address and waiting for the first > well-formed > >>>> response. > >>>> > > >>>> > > >>>> > Sure - an *implementation* of ActiveCluster API could > do exactly > >>>> that. > >>>> > > >>>> ??? > >>>> > >>>> well, maybe I'm thinking of the wrong piece of activecluster > >>>> then ? > >>>> > >>>> any piece of code could broadcast a packet... which piece of > >>>> activecluster's API are you suggesting here ? > >>>> > >>>> we really are talking about just a remoting proxy which > needs to > >>>> find, > >>>> but not 'join' a cluster. > >>>> > >>>> can you be more specific ? > >>>> > >>>> Jules > >>>> > >>>> > >>>> > James > >>>> > ------- > >>>> > http://radio.weblogs.com/0112098/ > >>>> > >>>> > >>>> > >>>> -- "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. > >>>> **********************************/ > >>>> > >>>> > >>> > >>> > > > > > > > -- > "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. > **********************************/ > > > > > -- > Ryan Thomas > r.n.thomas@gmail.com -- "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. **********************************/