Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
From: Sanjaya Karunasena <sanjayak@wso2.com>
Organization: WSO2
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Adding ClusterManager code the the codebase
Date: Mon, 5 Feb 2007 14:23:22 +0530
User-Agent: KMail/1.9.5
References: <9d4ec10b0702010946q13843d0q818e6e14ffcec62e@mail.gmail.com>
 <f5f5e0730702020650o45b7887bw1395393aec3fe7f8@mail.gmail.com>
 <f5f5e0730702042105m3c810e67o12bd291e699e446e@mail.gmail.com>
In-Reply-To: <f5f5e0730702042105m3c810e67o12bd291e699e446e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200702051423.23141.sanjayak@wso2.com>

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 <rajith77@gmail.com> 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 < chamikaramj@gmail.com> 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 < rajith77@gmail.com> 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 <  chamikaramj@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org