axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: [axis2] Clustering prototype available
Date Mon, 12 Feb 2007 14:53:45 GMT
Hey Chamikara,

Thanks for making the changes, I was busy with Qpid work so couldn't even do
the Null change we discussed.

However I have a concern about moving updateState from the Engine and
placing this in a handler.
The handler approach will only work if the MEP is IN_OUT.

If this is a IN_ONLY operation then there is no outflow, so update state
wan't be called. That is why I put it in the engine.
(see the disscussion on the other clustering thread, about using
flowComplete() as a replication point)

Regards,

Rajith

On 2/12/07, Chamikara Jayalath <chamikaramj@gmail.com> wrote:
>
> Hi Deepal,
>
> On 2/12/07, Deepal Jayasinghe <deepal@opensource.lk> wrote:
> >
> > Hi Chamikara;
> >
> > > Hi Rajith, All,
> > >
> > > I did some changes to the clustering code. Please send your comments
> > ...
> > >
> > > 1. Changed signatures of the addContext, removeContext, updateState
> > > methods to take an AbstractContext.
> > >
> > > This makes the methods more general. IDs can be always obtained by
> > > going through the passed contexts correctly.
> > >
> > > 2. Added a flush() method to the AbstractContexst which calls the
> > > clusterManager.updateState() method when clustering is enabled.
> >
> Can we change the method name flush() , how about update();
>
>
>
> I'm OK with changing the name. But not sure weather 'update' is the
> correct name.
> The idea of this method is to notify Axis2 to get sync with the updated
> state of the context (In our case replication).
>
> Chamikara
>
>
> >
> > > This allows Service authors to write their code in a transparent
> > > manner. I.e . if they hv done their state changes with flush() calls
> > > they will not have to do any changes to make their services
> > clusterable.
> > >
> > > 3. Moved the replication point of the execution chain into a Handler.
> > >
> > > There is no need to hard code this into the AxisEngine or
> > > MessageReceiver. By placing the ReplicationHandler anywhere in the
> > > handler chain we can change the replication point as needed. Most
> > > probably this will be placed at the end of the flows.
> > > (please see the clustering/conf/axis2.xml).
> > >
> > > 4. Added a isContextClusterable (AbstractContext) method to the CM.
> > >
> > > ClusterManagers can say what contexts they are interested in
> > > clustering, this will be useful to the Service authors.
> > >
> > > 5. Moved the addContext() method calls out of the constructors of the
> > > Context classes.
> > >
> > > It seems like it's better to have these outside. When we are in the
> > > constructor we do not have a fully initiated context object. For e.g.
> > > the serviceGroupContextId does not get setted at the time the SGC get
> > > created.
> > > Currently, this made me call clusterManager methods from several
> > > places of the core. But I was talking to Deepal about introducing some
> > > factories to create Context classes, which will make things much
> > cleaner.
> >
> > Yes , let's do that. And that will cleanup the code as well.
> >
> > >
> > > 6. Removed the NullClusterManager - as we discussed in the mailing
> > list.
> > >
> > > I also got your sample working with these changes. Will try to do some
> > > additions to it.
> >
> > Great.
> >
> > Thanks
> > Deepal
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>

Mime
View raw message