Hi All,
Since I am interested in distributed computing, I am closely monitoring this
discussion on clustering. I am still going through the code to understand the
approach/design/implementation. Since I am new to this codebase I have very
little understanding about most of the implementations. However I hope these
comments will help you all to define a scalable, flexible clustering
implementation for Axis2.
In a distributed scenario having the ability to handle concurrency is very
important. How do you tackle conflicting updates? There should be a way to
rollback/commit. In otherwords the interface should be transactionable. Also
having the ability to distinguish between read-only vs read/write access to
the context is an opportunity to apply some optimizations to the actual
implementation. I suggest that this interface should provide some means to do
that too.
I think the intention of abstracting the cluster manager to an interface is to
provide extensibility so that we can have different cluster manager
implementations based on different group communication techniques. But I
think right now the interface has introduced more coupling.
Following is an approach which could reduce coupling and enable more
flexibility and extensibility.
Do we have the ability to register a listener to the Context? What I mean is
an instance of a class which implements an interface ContextListner. The
ContextListner has one method "notify" which take a parameter of
type "Event". The ClusterManager interface can extend the ContextListner
(BTW, Should ClusterManger be an abstract class?)
This way, in a particular node when there is change in the Context the
ClusterManager instance in that node get notify. Then that ClusterManger
instance can mulitcast (reliable mulitcasting) the change to other
ClusterManger instances running in other nodes. Since each ClusterManager
instance has a handler to the Context it can apply the change locally. If the
reliable multicast is configured to keep the "total order" in message
ordering you don't have to worry about the conflicts due to concurrency.
This approach can be further optimized/enhanced based on different usecases.
Thanks and best regards,
Sanjaya
* There is no difference
On Monday 05 February 2007 10:35, Rajith Attapattu wrote:
> Chamikara,
>
> The code is available under branches/clustering.
>
> Here are the changes I made to ClusterManager interface. Of course what I
> did is just a prototype so feel free to experiment and change things.
>
> public abstract void init (ConfigurationContext context);
> public abstract void addContext (AbstractContext context);
> public abstract void removeContext (AbstractContext context);
>
> public abstract void updateState (AbstractContext context);
>
> As you can the changes are where I replaced the add/remove/touch property
> methods with a single updateState method.
> I found it to be very cumbersome/expensive to intercept the property
> changes and keep track of them on a per occurence basis.
> Instead a single updateState method called at the end of the invocation
> provides better alternative to handle the state changes. YMMV.
>
> looking forward to your comments on the prototype.
>
> Regards,
>
> Rajith
>
> On 2/2/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
> > Yes the implementation is build on top of the cluster manager.
> > I changed the method signatures slightly. But it's only a prototype.
> >
> > I will not check it into the trunk, untill we run a successfull demo and
>
> everybody is comfortable.
>
> > I will put that in a branch and then you guys can also make changes.
> >
> > Regards,
> >
> > Rajith
> >
> > On 2/2/07, Chamikara Jayalath < [EMAIL PROTECTED]> wrote:
> > > Rajith,
> > >
> > > What we are adding here is the interface that we agreed sometime back.
>
> So nothing prevents your implementation from working on top of that.
>
> > > BTW, what were the modifications that were done to the interface.
> > >
> > > Chamikara
> > >
> > > On 2/2/07, Rajith Attapattu < [EMAIL PROTECTED]> wrote:
> > > > Chamikara,
> > > >
> > > > I do have half baked impl sitting on my laptop based on a slightly
>
> modified cluster manager.
>
> > > > I will soon check this into a branch and you guys can then start
>
> playing around with it.
>
> > > > Sorry about this taking time, I was so occupied with the Qpid work.
> > > >
> > > > Regarda,
> > > >
> > > > Rajith
> > > >
> > > > On 2/1/07, Chamikara Jayalath < [EMAIL PROTECTED]> wrote:
> > > > > Hi All,
> > > > >
> > > > > As we discussed and agreed sometime back we will be adding an
>
> abstraction layer to Axis2 to make it possible to transparently plug-in
> different clustering implementations. Our abstraction was named
> 'ClusterManager' and the interface that was proposed is given in [1] (with
> some slight modifications).
>
> > > > > I am hoping to go a step forward my adding this interface to the
>
> Axis2 code base. At initiation Axis2 will load a ClusterManager
> implementation object (if configured) and will call the methods of it
> whenever respective events occur.
>
> > > > > Chamikara
> > > > >
> > > > >
> > > > > [1] ClusterManager interface
> > > > >
> > > > > public abstract class ClusterManager {
> > > > >
> > > > > public abstract void init (ConfigurationContext context);
> > > > > public abstract void addContext (AbstractContext context);
> > > > > public abstract void removeContext (AbstractContext context);
> > > > > public abstract void addProperty (AbstractContext context,
>
> String propertyName, Object propertyValue);
>
> > > > > public abstract void removeProperty (AbstractContext context,
>
> String propertyName);
>
> > > > > public abstract void touchProperty (AbstractContext context,
>
> String propertyName);
>
> > > > > public abstract void commit ();
> > > > >
> > > > > }
--
Senior Software Architect
WSO2 Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
