Hi Sanjaya, All,
So this implies that we need to keep the setProperty, getProperty methods of
the ClusterManager. Rajith ?
There is another reason. What about the service state. The service authors
will simply put the properties to the context classes and expect them to be
replicated. A single updateState method will not be sufficient to cater for
this.
Chamikara
On 2/7/07, Sanjaya Karunasena <[EMAIL PROTECTED]> wrote:
Hi Chamikara,
Please see my comments below.
Regards,
Sanjaya
On Wednesday 07 February 2007 10:32, Chamikara Jayalath wrote:
> Hi Sanjaya, Rajith, All,
>
> Having a dedicated getClusterManager() method in the AxisConfigurator
kind
> of implies that the ClusterManager setting will be a special part in the
> axis2.xml (guys, please correct me if I'm wrong).
> So I think it's better to hv it in the current way.
>
> There is another thing that hit my mind. What if a certain
ClusterManager
> implementation needs to do total ordering of event updates. Or what if
it
> decides to replicate the data as and when the events happen. In such a
> scenario calling a single 'updateState' method at the end of the
execution
> will not be sufficient. If we need to plan for this, we may be need to
go
> for something like the ContextListner approach that was sugested by
> Sanjaya.
>
This is the point I have discussed in my previous mail to the group. The
decision should be where to invest. Always there is a cost in terms of
performance, complexity, extensibility, scalability, etc. Single
updateState
works fine in a small scale setup and very well could be the one to use in
most of the deployments. But in a large cluster when there are lot of
conflicts locking techniques not going to scale.
In my opinion, having the ability to have different configurations based
on
the application need is very important. We cannot have a single solution
which can cater for all the scenarios while providing high values for all
the
QoS attributes.
> Performance wise we can reduce this to a 'null' check in property
set,get
> methods. I don't think this will be a much issue. Guys comments ?
>
Null check should get converted to a single instruction in the CPU compare
to
a method call which requires saving the state of the CPU registers and
restoring them. According to the Java documentation, Java compiler
optimizes
the property set and get methods to direct variable access so that they
are
not expensive as method calls.
> Chamikara
>
> On 2/7/07, Sanjaya Karunasena <[EMAIL PROTECTED]> wrote:
> > Hi Chamikara,
> >
> > I think it should be a configuration parameter which says whether
> > clustering
> > is enabled or disabled, defult to disabled.
> >
> > Sanjaya
> >
> > On Tuesday 06 February 2007 20:46, Chamikara Jayalath wrote:
> > > Hi Bill, Dims,
> > >
> > > The ClusterManager impl will be initiated with the ConfigContext.
This
> >
> > will
> >
> > > be called in places like Context Creation and removal and may be
> >
> > property
> >
> > > updates (hvnt fully decided yet). When Clustering is not present the
> >
> > cost
> >
> > > should be reduced to a null check.
> > >
> > > Chamikara
> > >
> > > On 2/6/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> > > > Bill,
> > > >
> > > > from what i understand, it's in a separate maven module. Not in
> > > > kernel. So you can ignore it :)
> > > >
> > > > -- dims
> > > >
> > > > On 2/6/07, Bill Nagy <[EMAIL PROTECTED]> wrote:
> > > > > What is the cost of this going to be for someone who doesn't
want
> > > > > clustering/this particular approach to clustering? I can't
infer
> >
> > much
> >
> > > > > from the interface -- exactly which respective events are you
> >
> > referring
> >
> > > > > to?
> > > > >
> > > > > -Bill
> > > > >
> > > > > On Thu, 2007-02-01 at 23:16 +0530, Chamikara Jayalath wrote:
> > > > > > 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 ();
> > > > > >
> > > > > > }
> >
> > ---------------------------------------------------------------------
> >
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > > --
> > > > Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services
> > > > Developers
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Senior Software Architect
> > WSO2 Inc.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
--
Senior Software Architect
WSO2 Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
