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