geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: [wadi-dev] Re: [Geronimo] Clustering
Date Thu, 12 Jan 2006 11:51:41 GMT
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* <jules@coredevelopers.net 
> <mailto:jules@coredevelopers.net>> 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* <rajith.attapattu@redknee.com
>     <mailto:rajith.attapattu@redknee.com>
>     >>>> <mailto:rajith.attapattu@redknee.com
>     <mailto:rajith.attapattu@redknee.com>>> wrote:
>     >>>>
>     >>>>
>     >>>>
>     >>>>     -----Original Message-----
>     >>>>     From: Jules Gosnell [mailto: jules@coredevelopers.net
>     <mailto:jules@coredevelopers.net>
>     >>>>     <mailto:jules@coredevelopers.net
>     <mailto:jules@coredevelopers.net>>]
>     >>>>     Sent: Monday, December 19, 2005 9:55 AM
>     >>>>     To: dev@wadi.codehaus.org <mailto:dev@wadi.codehaus.org>
>     <mailto:dev@wadi.codehaus.org <mailto:dev@wadi.codehaus.org>>
>     >>>>     Cc: wadi-dev@incubator.apache.org
>     <mailto:wadi-dev@incubator.apache.org>
>     >>>>     <mailto:wadi-dev@incubator.apache.org
>     <mailto:wadi-dev@incubator.apache.org>>; dev@geronimo.apache.org
>     <mailto:dev@geronimo.apache.org>
>     >>>>     <mailto: 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> <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 <http://www.coredevelopers.net>
>     *
>     * Open Source Training & Support.
>     **********************************/
>
>
>
>
> -- 
> Ryan Thomas
> r.n.thomas@gmail.com <mailto: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.
 **********************************/


Mime
View raw message