On 19 Dec 2005, at 11:53, Jules Gosnell wrote:
Rajith Attapattu wrote:
Jules,
Sorry for the late reply and thanks for all the info!!! It's awesome.
I have more questions if you don't mind. Not very organized so
bear with me :(
no problem.
Answers are greatly appreciated.
JNDI implementation
--------------------
I guess what you are talking about is our own version of (at the
least)JNDI Context implementation that is cluster aware and the
lookup is based on the various strategies outlined in your email.
(This is where I guess Apache directory can be leveraged to build
our impl on top)
I think so.
ActiveSpace may be useful here.
Agreed - its pretty trivial to use ActiveSpace with its optimistic
locking as a provider for JNDI.
The distributed caching problem space is large and varied. wadi-
core is designed very much with a particular subset of this space
in mind. This is the area concerned with numbers of distributed
objects that are too great to be held on a single node and that are
frequently written and read and require pessimistic locking
policies to be used in their manipulation. JNDI has slightly
different requirements. Objects placed in JNDI are generally few,
rarely written (only on [un]deployment) and frequently read.
Optimistic locking policies may be sufficient.
For directory services which are very read-centric and performance is
an issue, then I'd recommend an optimistic locking mechanism.
Ultimately, wadi-core and ActiveSpace are complimentary
technologies, both providing solutions to different areas of this
problem space. WADI also contains lots of integration code to
various other containers, so I am imagining a situation where a
layer of WADI code integrates Geronimo, Apache Directory and
ActiveSpace, all sitting on top of ActiveCluster and ActiveMQ.
FWIW I'd have preferred us to create a 'cluster' subproject at
Geronimo where various different kinds of clustering & caching &
state management could be unified (plus i'm not keen on WADI as a
project name :) - then we can merge the code bases from
ActiveCluster, ActiveSpace & WADI into modules which make sense (e.g.
pessimistic locking models, optimistic locking models, caching,
distributed/movable state etc.).
Plus you are taked about passing in membership information to the
client via a proprietary protocol or the client taking on itself
to obtain membership info via configuration or an auto discovery
handle.
Correct. We may well settle on ActiveCluster as the API for
membership.
Unless you can come up with a better API, I'd recommend ActiveCluster
as its whole design was to act as a simple POJO model for discovery
of nodes such that anything can be plugged in the back. Other than
reusing a few trivial interfaces from JMS; its easy to implement
using any technology whatsoever.
I am not sure whether we can reuse autodiscovery code from ActiveMQ
(which uses it to connect peers when running on its peer://
protocol stack)
Thats very ActiveMQ transport specific - I'd avoid it if I were you -
especially if one of your goals is to avoid having to suck in the
whole of ActiveMQ :).
, 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.
James
-------
http://radio.weblogs.com/0112098/
