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 16:42:38 GMT
A big +1 for this proposal.

>2. Do not call the ContextListner in property get, set methods.
>- These events will not be captured by the listener.
In my opinion this is key for performance. Now this gives rise to the
problem waiting to long for replication, especially in the case of long
running invocations or asynch invocations (where the message receiver
returns before the "business logic" is fully executed.

To counter that we disscussed on the other clustering thread the following
proposal.
We can introduce two modes.
1) Container Managed replication
2) Service Managed replication.

Container managed replication will call update state when the container
things it's time to do so.
With user managed replication the service author has the discreetion in
calling updateState when ever he wants. The service author can call it for
every property change or at any given point as the author things it's
appropriate.

If we can get the ContextListerner going on the trunk we can quiclky add
that to the cluster branch. Deepal ?????

Rajith

On 2/12/07, Chamikara Jayalath <chamikaramj@gmail.com> wrote:
>
> Hi Rajith, All,
>
> ReplicationHandler can be placed at various places of the Handler chain
> and it does replication both at its 'invoke' and 'flowComplete' methods.
> FlowComplete methods get called after the invocation of the MessageReceiver,
> so the state of the contexsts get replicated without a problem even in the
> InOnly case.
>
> Introducing this handler made things more flexible and reduced coupling. I
> have another suggestion that could reduce coupling further.
>
> The idea is to introduce a ContextListner. This will get called in
> specific places like,
> 1. When a context get created
> 2. When a context get removed
> 3. When a context get flushed.
>
> If we can have this feature we will be able to move clustering code into a
> module. At initiation this module will register a ContextListener which will
> allow it to listen to context updates.
>
> For having a minimum affect on the performance there are several things we
> can do.
>
> 1. Do not initialize the ContextListner Map until the first Listener is
> added.
> - This reduces the load to a 'null' check when no listeners are available.
>
>
> 2. Do not call the ContextListner in property get, set methods.
> - These events will not be captured by the listener.
>
> 3. Not all the contexts should call the listeners.
>  - For e.g. we may decide not to call the ContextListeners for events of
> the MessageContexts.
>
> This will not have any performance drawback from the approach we are
> following now. But it will allow us to fully decouple clustering code from
> the kernel.
>
> What do u think ?
>
>
> Chamikara
>
>
>
>
> On 2/12/07, Rajith Attapattu <rajith77@gmail.com > wrote:
> >
> > 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