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?
Cheers,
-Ryan
On 1/12/06, Jules Gosnell <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED]
>>>> <mailto:[EMAIL PROTECTED] >> wrote:
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Jules Gosnell [mailto: [EMAIL PROTECTED]
>>>> <mailto:[EMAIL PROTECTED]>]
>>>> Sent: Monday, December 19, 2005 9:55 AM
>>>> To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>>>> Cc: wadi-dev@incubator.apache.org
>>>> <mailto:wadi-dev@incubator.apache.org>; dev@geronimo.apache.org
>>>> <mailto: 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 <http://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
[EMAIL PROTECTED]
