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* <[EMAIL PROTECTED] <mailto:[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]>
    >>>> <mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>>> wrote:
    >>>>
    >>>>
    >>>>
    >>>>     -----Original Message-----
    >>>>     From: Jules Gosnell [mailto: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    >>>>     <mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>>]
    >>>>     Sent: Monday, December 19, 2005 9:55 AM
    >>>>     To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
    <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
    >>>>     Cc: [email protected]
    <mailto:[email protected]>
    >>>>     <mailto:[email protected]
    <mailto:[email protected]>>; [email protected]
    <mailto:[email protected]>
    >>>>     <mailto: [email protected]
    <mailto:[email protected]>>
    >>>>     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
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>



--
"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.
**********************************/

Reply via email to