You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Rajith Attapattu <ra...@gmail.com> on 2007/02/05 05:54:45 UTC
[axis2] Clustering prototype available
Hi folks,
I have a working prototype for clustering based on the ClusterManager (we
discussed this in a thread before) and Apache Tribes.
I have created a branch for this (based on rev 503540 in trunk), so that
interested parties can experiment with it.
https://svn.apache.org/repos/asf/webservices/axis2/branches/java/clustering/
before compiling the code please install
http://people.apache.org/~rajith/axis2-clustering/apache-tribes-0.9.5.2.jarin
your local maven repo under tribes.
I have tested this with 6 nodes. The basic functionality is to replicate the
service group context and the service context including the property bags.
I still need to work on garbage collecting the ctx's when they are removed
from the primary node.
I have a Sample Account Service which I used to test the implementation at
the follwing link. (both source and .aar file)
http://people.apache.org/~rajith/axis2-clustering/
To test, just proxy all operation via TCPMon, which will allow you to point
at different nodes w/o restarting the clinet.
Once you do the login operation in one node, feel free to run the other
operations against different nodes via the TCPMon.
Before running the example please, please copy
http://people.apache.org/~rajith/axis2-clustering/apache-tribes-0.9.5.2.jarinto
your classpath as I haven't changed the scripts to copy this into the
axis2 distributions.
Please try it out and provide feedback, better yet if you can contribute to
improve it.
Regards,
Rajith Attapattu
Red Hat.
Re: [axis2] Clustering prototype available
Posted by Rajith Attapattu <ra...@gmail.com>.
Bill,
We are happy to outline the differences and perhaps provide more
documentation.
But as chamikara pointed out, some feedback at this initial stages can help
a lot.
Regards,
Rajith
On 2/12/07, Chamikara Jayalath <ch...@gmail.com> wrote:
>
> Yes. We can do that.
> But it will be much helpful if you can give your feedback while the idea
> being discussed (so that we will not have to keep doing changes repeatedly)
>
> Thanks,
> Chamikara
>
>
> On 2/12/07, Bill Nagy <na...@watson.ibm.com> wrote:
> >
> > When you guys get to a state that you are happy with, could you please
> > generate and post a diff between your branch and the trunk, so those of
> > us that are time-impaired can be clear as to exactly what is being done?
> >
> > Thanks.
> >
> > -Bill
> >
> >
> > On Mon, 2007-02-12 at 11:42 -0500, Rajith Attapattu wrote:
> > > 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 <ch...@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 <ch...@gmail.com>
> > > wrote:
> > > Hi Deepal,
> > >
> > > On 2/12/07, Deepal Jayasinghe
> > > <de...@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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
Re: [axis2] Clustering prototype available
Posted by Chamikara Jayalath <ch...@gmail.com>.
Yes. We can do that.
But it will be much helpful if you can give your feedback while the idea
being discussed (so that we will not have to keep doing changes repeatedly)
Thanks,
Chamikara
On 2/12/07, Bill Nagy <na...@watson.ibm.com> wrote:
>
> When you guys get to a state that you are happy with, could you please
> generate and post a diff between your branch and the trunk, so those of
> us that are time-impaired can be clear as to exactly what is being done?
> Thanks.
>
> -Bill
>
>
> On Mon, 2007-02-12 at 11:42 -0500, Rajith Attapattu wrote:
> > 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 <ch...@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 <ra...@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 <ch...@gmail.com>
> > wrote:
> > Hi Deepal,
> >
> > On 2/12/07, Deepal Jayasinghe
> > <de...@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
> >
> >
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [axis2] Clustering prototype available
Posted by Bill Nagy <na...@watson.ibm.com>.
When you guys get to a state that you are happy with, could you please
generate and post a diff between your branch and the trunk, so those of
us that are time-impaired can be clear as to exactly what is being done?
Thanks.
-Bill
On Mon, 2007-02-12 at 11:42 -0500, Rajith Attapattu wrote:
> 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 <ch...@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 <ra...@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 <ch...@gmail.com>
> wrote:
> Hi Deepal,
>
> On 2/12/07, Deepal Jayasinghe
> <de...@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
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Clustering prototype available
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <ch...@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
> > > >
> > > >
> > >
> >
>
Re: [axis2] Clustering prototype available
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ra...@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
> > >
> > >
> >
>
Re: [axis2] Clustering prototype available
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <ch...@gmail.com> wrote:
>
> Hi Deepal,
>
> On 2/12/07, Deepal Jayasinghe <de...@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
> >
> >
>
Re: [axis2] Clustering prototype available
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Deepal,
On 2/12/07, Deepal Jayasinghe <de...@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
>
>
Re: [axis2] Clustering prototype available
Posted by Deepal Jayasinghe <de...@opensource.lk>.
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();
>
> 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
Re: [axis2] Clustering prototype available
Posted by Chamikara Jayalath <ch...@gmail.com>.
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.
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.
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.
Chamikara
On 2/5/07, Rajith Attapattu <ra...@gmail.com> wrote:
>
> Hi folks,
>
> I have a working prototype for clustering based on the ClusterManager (we
> discussed this in a thread before) and Apache Tribes.
> I have created a branch for this (based on rev 503540 in trunk), so that
> interested parties can experiment with it.
>
> https://svn.apache.org/repos/asf/webservices/axis2/branches/java/clustering/
> before compiling the code please install http://people.apache.org/~rajith
> /axis2-clustering/apache-tribes-0.9.5.2.jar<http://people.apache.org/%7Erajith/axis2-clustering/apache-tribes-0.9.5.2.jar>in your local maven repo under tribes.
>
> I have tested this with 6 nodes. The basic functionality is to replicate
> the service group context and the service context including the property
> bags.
> I still need to work on garbage collecting the ctx's when they are removed
> from the primary node.
>
> I have a Sample Account Service which I used to test the implementation at
> the follwing link. (both source and .aar file)
> http://people.apache.org/~rajith/axis2-clustering/<http://people.apache.org/%7Erajith/axis2-clustering/>
>
> To test, just proxy all operation via TCPMon, which will allow you to
> point at different nodes w/o restarting the clinet.
> Once you do the login operation in one node, feel free to run the other
> operations against different nodes via the TCPMon.
>
> Before running the example please, please copy http://people.apache.org/~
> rajith/axis2-clustering/apache-tribes-0.9.5.2.jar<http://people.apache.org/%7Erajith/axis2-clustering/apache-tribes-0.9.5.2.jar>into your classpath as I haven't changed the scripts to copy this into the
> axis2 distributions.
>
> Please try it out and provide feedback, better yet if you can contribute
> to improve it.
>
> Regards,
>
> Rajith Attapattu
> Red Hat.
>