On 1/12/06, Jules Gosnell <[EMAIL PROTECTED]> wrote:
I'm interested in the deployment and lifecycle management as well as the overall cluster management (node discovery, failover etc).
Having used JBoss for a number of years (writing and deploying apps), I think that the clustering is one of the coolest parts!!
If you could hook me up with anything in those area's I'd much appreciate it.
Cheers,
-Ryan
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 :-)
I'm interested in the deployment and lifecycle management as well as the overall cluster management (node discovery, failover etc).
Having used JBoss for a number of years (writing and deploying apps), I think that the clustering is one of the coolest parts!!
If you could hook me up with anything in those area's I'd much appreciate it.
Cheers,
-Ryan
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: 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
> [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.
**********************************/
--
Ryan Thomas
[EMAIL PROTECTED]
