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 2006/10/19 21:52:10 UTC
[axis2] Clustering impl using tribes
Hi All,
I have built a clustering prototype for axis2 using tribes. However here are
my observations which really concerns me.
I slighlty modified the interface proposed by chamikara (modifications are
just addition of parameters to the methods) to get this working.
The interface is actually a very good abstraction, how ever the existing
axis2 architecture falls short of expectation in making it a good fit.
Ideas are welcome to improve on this (given that the axis2 architecture is
static)
I have broken them down to practical issues and architectural issues.
Architectural concerns which reduce the usability of the proposed Interface
--------------------------------------------------------------------------------------------------------------
A) The Context heirachy has no common interface, therefore we cannot treat
both ServiceContext and ServiceGroupContext as the same due to the following
reasons
1.) There is no context id associated with ServiceContext, therefore
just having the context id as a parameter is not good enough
2.) We cannot use the ReplicatedHashMap provided by Tribes without
introducing a dependency to kernal module on Tribes.
If we had an interface we could have created a
ReplicatedServiceContext and ReplicatedServiceGroupContext implementing the
interface.
B) Even if we had an interface, the creation of Contexts are done all over
the place, instead through a Factory class, therefore limiting the
possibility of supplying a Replicated context without introducing a hard
dependency on tribes to kernal module.
We have 2 possible solutions to avoid a dependency.
1.) Delegate the setProperty(k,v) & setProperties(map) method to the impl
via the interface and then use low level tribes API to do the replication.
This is a pain in the ass as we have to manage synchronization manually
across the cluster. Reinventing wheel...not in a mood to do so :)
2.) Manage a set of Maps at the implementation level which are wrapped with
ReplicatedMap, and then we only need to sync with the maps in the context.
This is ugly, but it works with minimal effort.
Practical issues
-----------------------
1.) The context id for service groups are not set at creation time, so we
cannot replicate the creation of a service group context until a context id
is set.
2.) A Service context cannot exist without a Service Group context, however
before we have a id for service group context a service context is created
for the service.
So we have to hold on to the service context, until we have a id for
service group context, then replicated the group ctx and then the service
ctx.
Any solutions to this problem?
Regards,
Rajith
Re: [axis2] Clustering impl using tribes
Posted by Chamikara Jayalath <ch...@gmail.com>.
OK. Waiting for it :-)
Chamikara
On 10/25/06, Rajith Attapattu <ra...@gmail.com> wrote:
>
> Hi Chamikara,
>
> give me time till this weekend and I will get a compilable and "barely
> workable" code commited to a sandbox.
> This week I am busy with CSS and I also have to do some stuff on Qpid and
> Tuscany :(
>
> I have used the ClusterManager with some slight modifications to
> parameters and my concern is not with the ClusterManager (by the way thats
> probably the best solution given our situation), but with the difficulty in
> capturing the event properly and supplying them to the ClusterManager as
> well as doing the cumbersome low level stuff.
>
> Let me first post the code and then let me send an email point out to the
> problem areas in the code.
> Based on that we can work together to find a solution.
>
> Regards,
>
> Rajith
>
> On 10/24/06, Chamikara Jayalath <ch...@gmail.com> wrote:
> >
> > Hi David,
> >
> > It was discussed here.
> >
> > http://marc.theaimsgroup.com/?t=115522886000003&r=1&w=2
> >
> > Chamikara
> >
> >
> > On 10/24/06, David Illsley <davidillsley@gmail.com > wrote:
> > >
> > > OK, I wasn't fully up to speed on the new ClusterManager interface.
> > > You make a good point... though if someone were to do the Factory work
> > > I'd still be +1 :-)
> > >
> > > Oh, where is the ClusterManager interface so I can have a better look
> > > at it?
> > > Thanks,
> > > David
> > >
> > > On 24/10/06, Chamikara Jayalath <ch...@gmail.com> wrote:
> > > > Hi David,
> > > >
> > > > I understand that if we were were trying to put some code that is
> > > dependent
> > > > on a particular clustering implementation into Axis2, we need to
> > > hide that
> > > > code. But the situation here is a bit different.
> > > >
> > > > What we introduced was a ClusterManager interface. This will live
> > > within
> > > > Axis2. Now should the rest of the Axia2 code be completely unaware
> > > of this
> > > > interface. I think it should not.
> > > >
> > > > In this particular scenario i'm talking about some method of Axis2
> > > Context
> > > > classes which can be called for serializing their states (sorry abt
> > > calling
> > > > it 'replicate' may be we should simply call it 'serializeState'). If
> > > > somebody have configured Axis2 to enable clustering and if somebody
> > > have
> > > > mentioned an ClusterManager implementation in the axis2.xml . Some
> > > methods of
> > > > it will be also called.
> > > >
> > > > I think introducing a factory to create Contexts will introduce an
> > > > unnecessary complexity. Still there may be many other places where
> > > we may
> > > > directly have to call the methods of the ClusterManager interface.
> > > >
> > > > Chamikara
> > > >
> > > >
> > > >
> > > >
> > > > On 10/23/06, David Illsley <davidillsley@gmail.com > wrote:
> > > > >
> > > > > Moving to a factory creation style which allows the base Axis2
> > > > > implementations to not contain any clustering code sounds simplest
> > > and
> > > > > most attractive to me.
> > > > >
> > > > > David
> > > > >
> > > > > On 21/10/06, Chamikara Jayalath < chamikaramj@gmail.com> wrote:
> > > > > > Hi Rajith,
> > > > > >
> > > > > > Please see my comments below.
> > > > > >
> > > > > > On 10/20/06, Rajith Attapattu < rajith77@gmail.com> wrote:
> > > > > > > Deepal,
> > > > > > >
> > > > > > > Thanks for your answers, I really appreciate it.
> > > > > > >
> > > > > > > >There is an id associate with ServiceGroupContext , so once
> > > you have
> > > > SGC
> > > > > > > >from the you can get the service context . Then the id of the
> > > SC will
> > > > be
> > > > > > > >the name of the corresponding AxisService.
> > > > > > > That is what I did so far, but service name is not a unique
> > > id.
> > > > > > > However can a service by the same name can exist in a diffrent
> > > service
> > > > > > group ???
> > > > > > >
> > > > > > > For now I use service group id + service name as a unique key.
> > >
> > > > > > >
> > > > > > > >>How big is the jar ?
> > > > > > > Deepal we should not have dependency on tribes as our
> > > clustering
> > > > > > implementation. So even if it's a samll jar we should decouple
> > > the
> > > > > > clustering impl from the kernal.
> > > > > > > Sanjiva also has an idea of using Richochet in the future, so
> > > we
> > > > should be
> > > > > > able to implement that without doing too much work.
> > > > > > >
> > > > > > > >What do you mean by all over th place , as I know all of them
> > > are
> > > > > > > > created inside instance dispatcher.
> > > > > > >
> > > > > > >
> > > > > > > Sorry if I didn't explain the point properly.
> > > > > > >
> > > > > > > For example ServiceContext is created inside the
> > > getServiceContext()
> > > > > > method in the ServiceGroupContext class
> > > > > > > then ServiceGroupContext is created inside
> > > ConfigurationContext in the
> > > > > > method fillServiceContextAndServiceGroupContext ()
> > > > > > >
> > > > > > > What I really wanted to highlight was, not where the places we
> > > do a
> > > > new
> > > > > > XXXContext(), but rather if we wanted to control the creation
> > > through a
> > > > > > factory class then all we have to do is to change it there. Now
> > > we have
> > > > to
> > > > > > track down all the places we do new XXXContext() if want to
> > > control the
> > > > > > creation and we can't avoid to create new type of context, for
> > > example
> > > > > > ReplicatedServiceContext without introducing a dependency.
> > > > > > >
> > > > > > > What I would have liked to see is ( if possible) to hide the
> > > creation
> > > > of
> > > > > > the context behind a Factory class, so that during creation we
> > > could
> > > > serve a
> > > > > > Replicated context instead of a normal context transparently to
> > > the
> > > > code.
> > > > > >
> > > > > >
> > > > > > There is another way. We can introduce a 'replicate' method to
> > > the
> > > > > > AbstractContext. Each context can override this and have its
> > > own
> > > > > > replication logic. A a parent 'replicate' method may recursively
> > > call it
> > > > for
> > > > > > all the childs. So even if we want to replicate the whole
> > > context
> > > > hierarchy
> > > > > > it will be simple as calling this method from the
> > > ConfigurationContext
> > > > > > instance (we may not want to do that always).
> > > > > > BTW is it possible for you to commit the code to some place
> > > (scratch?)
> > > > so
> > > > > > that we can see what areas we can help on.
> > > > > >
> > > > > > Chamikara
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > David Illsley - IBM Web Services Development
> > > > >
> > > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > axis-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > David Illsley - IBM Web Services Development
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
>
Re: [axis2] Clustering impl using tribes
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Chamikara,
give me time till this weekend and I will get a compilable and "barely
workable" code commited to a sandbox.
This week I am busy with CSS and I also have to do some stuff on Qpid and
Tuscany :(
I have used the ClusterManager with some slight modifications to parameters
and my concern is not with the ClusterManager (by the way thats probably the
best solution given our situation), but with the difficulty in capturing the
event properly and supplying them to the ClusterManager as well as doing the
cumbersome low level stuff.
Let me first post the code and then let me send an email point out to the
problem areas in the code.
Based on that we can work together to find a solution.
Regards,
Rajith
On 10/24/06, Chamikara Jayalath <ch...@gmail.com> wrote:
>
> Hi David,
>
> It was discussed here.
>
> http://marc.theaimsgroup.com/?t=115522886000003&r=1&w=2
>
> Chamikara
>
>
> On 10/24/06, David Illsley <da...@gmail.com> wrote:
> >
> > OK, I wasn't fully up to speed on the new ClusterManager interface.
> > You make a good point... though if someone were to do the Factory work
> > I'd still be +1 :-)
> >
> > Oh, where is the ClusterManager interface so I can have a better look at
> > it?
> > Thanks,
> > David
> >
> > On 24/10/06, Chamikara Jayalath <ch...@gmail.com> wrote:
> > > Hi David,
> > >
> > > I understand that if we were were trying to put some code that is
> > dependent
> > > on a particular clustering implementation into Axis2, we need to hide
> > that
> > > code. But the situation here is a bit different.
> > >
> > > What we introduced was a ClusterManager interface. This will live
> > within
> > > Axis2. Now should the rest of the Axia2 code be completely unaware of
> > this
> > > interface. I think it should not.
> > >
> > > In this particular scenario i'm talking about some method of Axis2
> > Context
> > > classes which can be called for serializing their states (sorry abt
> > calling
> > > it 'replicate' may be we should simply call it 'serializeState'). If
> > > somebody have configured Axis2 to enable clustering and if somebody
> > have
> > > mentioned an ClusterManager implementation in the axis2.xml . Some
> > methods of
> > > it will be also called.
> > >
> > > I think introducing a factory to create Contexts will introduce an
> > > unnecessary complexity. Still there may be many other places where we
> > may
> > > directly have to call the methods of the ClusterManager interface.
> > >
> > > Chamikara
> > >
> > >
> > >
> > >
> > > On 10/23/06, David Illsley <da...@gmail.com> wrote:
> > > >
> > > > Moving to a factory creation style which allows the base Axis2
> > > > implementations to not contain any clustering code sounds simplest
> > and
> > > > most attractive to me.
> > > >
> > > > David
> > > >
> > > > On 21/10/06, Chamikara Jayalath < chamikaramj@gmail.com> wrote:
> > > > > Hi Rajith,
> > > > >
> > > > > Please see my comments below.
> > > > >
> > > > > On 10/20/06, Rajith Attapattu < rajith77@gmail.com> wrote:
> > > > > > Deepal,
> > > > > >
> > > > > > Thanks for your answers, I really appreciate it.
> > > > > >
> > > > > > >There is an id associate with ServiceGroupContext , so once you
> > have
> > > SGC
> > > > > > >from the you can get the service context . Then the id of the
> > SC will
> > > be
> > > > > > >the name of the corresponding AxisService.
> > > > > > That is what I did so far, but service name is not a unique id.
> > > > > > However can a service by the same name can exist in a diffrent
> > service
> > > > > group ???
> > > > > >
> > > > > > For now I use service group id + service name as a unique key.
> > > > > >
> > > > > > >>How big is the jar ?
> > > > > > Deepal we should not have dependency on tribes as our clustering
> > > > > implementation. So even if it's a samll jar we should decouple the
> >
> > > > > clustering impl from the kernal.
> > > > > > Sanjiva also has an idea of using Richochet in the future, so we
> > > should be
> > > > > able to implement that without doing too much work.
> > > > > >
> > > > > > >What do you mean by all over th place , as I know all of them
> > are
> > > > > > > created inside instance dispatcher.
> > > > > >
> > > > > >
> > > > > > Sorry if I didn't explain the point properly.
> > > > > >
> > > > > > For example ServiceContext is created inside the
> > getServiceContext()
> > > > > method in the ServiceGroupContext class
> > > > > > then ServiceGroupContext is created inside ConfigurationContext
> > in the
> > > > > method fillServiceContextAndServiceGroupContext ()
> > > > > >
> > > > > > What I really wanted to highlight was, not where the places we
> > do a
> > > new
> > > > > XXXContext(), but rather if we wanted to control the creation
> > through a
> > > > > factory class then all we have to do is to change it there. Now we
> > have
> > > to
> > > > > track down all the places we do new XXXContext() if want to
> > control the
> > > > > creation and we can't avoid to create new type of context, for
> > example
> > > > > ReplicatedServiceContext without introducing a dependency.
> > > > > >
> > > > > > What I would have liked to see is ( if possible) to hide the
> > creation
> > > of
> > > > > the context behind a Factory class, so that during creation we
> > could
> > > serve a
> > > > > Replicated context instead of a normal context transparently to
> > the
> > > code.
> > > > >
> > > > >
> > > > > There is another way. We can introduce a 'replicate' method to the
> > > > > AbstractContext. Each context can override this and have its own
> > > > > replication logic. A a parent 'replicate' method may recursively
> > call it
> > > for
> > > > > all the childs. So even if we want to replicate the whole context
> > > hierarchy
> > > > > it will be simple as calling this method from the
> > ConfigurationContext
> > > > > instance (we may not want to do that always).
> > > > > BTW is it possible for you to commit the code to some place
> > (scratch?)
> > > so
> > > > > that we can see what areas we can help on.
> > > > >
> > > > > Chamikara
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > David Illsley - IBM Web Services Development
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
Re: [axis2] Clustering impl using tribes
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi David,
It was discussed here.
http://marc.theaimsgroup.com/?t=115522886000003&r=1&w=2
Chamikara
On 10/24/06, David Illsley <da...@gmail.com> wrote:
>
> OK, I wasn't fully up to speed on the new ClusterManager interface.
> You make a good point... though if someone were to do the Factory work
> I'd still be +1 :-)
>
> Oh, where is the ClusterManager interface so I can have a better look at
> it?
> Thanks,
> David
>
> On 24/10/06, Chamikara Jayalath <ch...@gmail.com> wrote:
> > Hi David,
> >
> > I understand that if we were were trying to put some code that is
> dependent
> > on a particular clustering implementation into Axis2, we need to hide
> that
> > code. But the situation here is a bit different.
> >
> > What we introduced was a ClusterManager interface. This will live
> within
> > Axis2. Now should the rest of the Axia2 code be completely unaware of
> this
> > interface. I think it should not.
> >
> > In this particular scenario i'm talking about some method of Axis2
> Context
> > classes which can be called for serializing their states (sorry abt
> calling
> > it 'replicate' may be we should simply call it 'serializeState'). If
> > somebody have configured Axis2 to enable clustering and if somebody have
> > mentioned an ClusterManager implementation in the axis2.xml. Some
> methods of
> > it will be also called.
> >
> > I think introducing a factory to create Contexts will introduce an
> > unnecessary complexity. Still there may be many other places where we
> may
> > directly have to call the methods of the ClusterManager interface.
> >
> > Chamikara
> >
> >
> >
> >
> > On 10/23/06, David Illsley <da...@gmail.com> wrote:
> > >
> > > Moving to a factory creation style which allows the base Axis2
> > > implementations to not contain any clustering code sounds simplest and
> > > most attractive to me.
> > >
> > > David
> > >
> > > On 21/10/06, Chamikara Jayalath < chamikaramj@gmail.com> wrote:
> > > > Hi Rajith,
> > > >
> > > > Please see my comments below.
> > > >
> > > > On 10/20/06, Rajith Attapattu <ra...@gmail.com> wrote:
> > > > > Deepal,
> > > > >
> > > > > Thanks for your answers, I really appreciate it.
> > > > >
> > > > > >There is an id associate with ServiceGroupContext , so once you
> have
> > SGC
> > > > > >from the you can get the service context . Then the id of the SC
> will
> > be
> > > > > >the name of the corresponding AxisService.
> > > > > That is what I did so far, but service name is not a unique id.
> > > > > However can a service by the same name can exist in a diffrent
> service
> > > > group ???
> > > > >
> > > > > For now I use service group id + service name as a unique key.
> > > > >
> > > > > >>How big is the jar ?
> > > > > Deepal we should not have dependency on tribes as our clustering
> > > > implementation. So even if it's a samll jar we should decouple the
> > > > clustering impl from the kernal.
> > > > > Sanjiva also has an idea of using Richochet in the future, so we
> > should be
> > > > able to implement that without doing too much work.
> > > > >
> > > > > >What do you mean by all over th place , as I know all of them are
> > > > > > created inside instance dispatcher.
> > > > >
> > > > >
> > > > > Sorry if I didn't explain the point properly.
> > > > >
> > > > > For example ServiceContext is created inside the
> getServiceContext()
> > > > method in the ServiceGroupContext class
> > > > > then ServiceGroupContext is created inside ConfigurationContext in
> the
> > > > method fillServiceContextAndServiceGroupContext ()
> > > > >
> > > > > What I really wanted to highlight was, not where the places we do
> a
> > new
> > > > XXXContext(), but rather if we wanted to control the creation
> through a
> > > > factory class then all we have to do is to change it there. Now we
> have
> > to
> > > > track down all the places we do new XXXContext() if want to control
> the
> > > > creation and we can't avoid to create new type of context, for
> example
> > > > ReplicatedServiceContext without introducing a dependency.
> > > > >
> > > > > What I would have liked to see is ( if possible) to hide the
> creation
> > of
> > > > the context behind a Factory class, so that during creation we could
> > serve a
> > > > Replicated context instead of a normal context transparently to the
> > code.
> > > >
> > > >
> > > > There is another way. We can introduce a 'replicate' method to the
> > > > AbstractContext. Each context can override this and have its own
> > > > replication logic. A a parent 'replicate' method may recursively
> call it
> > for
> > > > all the childs. So even if we want to replicate the whole context
> > hierarchy
> > > > it will be simple as calling this method from the
> ConfigurationContext
> > > > instance (we may not want to do that always).
> > > > BTW is it possible for you to commit the code to some place
> (scratch?)
> > so
> > > > that we can see what areas we can help on.
> > > >
> > > > Chamikara
> > > >
> > > >
> > >
> > >
> > > --
> > > David Illsley - IBM Web Services Development
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [axis2] Clustering impl using tribes
Posted by David Illsley <da...@gmail.com>.
OK, I wasn't fully up to speed on the new ClusterManager interface.
You make a good point... though if someone were to do the Factory work
I'd still be +1 :-)
Oh, where is the ClusterManager interface so I can have a better look at it?
Thanks,
David
On 24/10/06, Chamikara Jayalath <ch...@gmail.com> wrote:
> Hi David,
>
> I understand that if we were were trying to put some code that is dependent
> on a particular clustering implementation into Axis2, we need to hide that
> code. But the situation here is a bit different.
>
> What we introduced was a ClusterManager interface. This will live within
> Axis2. Now should the rest of the Axia2 code be completely unaware of this
> interface. I think it should not.
>
> In this particular scenario i'm talking about some method of Axis2 Context
> classes which can be called for serializing their states (sorry abt calling
> it 'replicate' may be we should simply call it 'serializeState'). If
> somebody have configured Axis2 to enable clustering and if somebody have
> mentioned an ClusterManager implementation in the axis2.xml. Some methods of
> it will be also called.
>
> I think introducing a factory to create Contexts will introduce an
> unnecessary complexity. Still there may be many other places where we may
> directly have to call the methods of the ClusterManager interface.
>
> Chamikara
>
>
>
>
> On 10/23/06, David Illsley <da...@gmail.com> wrote:
> >
> > Moving to a factory creation style which allows the base Axis2
> > implementations to not contain any clustering code sounds simplest and
> > most attractive to me.
> >
> > David
> >
> > On 21/10/06, Chamikara Jayalath < chamikaramj@gmail.com> wrote:
> > > Hi Rajith,
> > >
> > > Please see my comments below.
> > >
> > > On 10/20/06, Rajith Attapattu <ra...@gmail.com> wrote:
> > > > Deepal,
> > > >
> > > > Thanks for your answers, I really appreciate it.
> > > >
> > > > >There is an id associate with ServiceGroupContext , so once you have
> SGC
> > > > >from the you can get the service context . Then the id of the SC will
> be
> > > > >the name of the corresponding AxisService.
> > > > That is what I did so far, but service name is not a unique id.
> > > > However can a service by the same name can exist in a diffrent service
> > > group ???
> > > >
> > > > For now I use service group id + service name as a unique key.
> > > >
> > > > >>How big is the jar ?
> > > > Deepal we should not have dependency on tribes as our clustering
> > > implementation. So even if it's a samll jar we should decouple the
> > > clustering impl from the kernal.
> > > > Sanjiva also has an idea of using Richochet in the future, so we
> should be
> > > able to implement that without doing too much work.
> > > >
> > > > >What do you mean by all over th place , as I know all of them are
> > > > > created inside instance dispatcher.
> > > >
> > > >
> > > > Sorry if I didn't explain the point properly.
> > > >
> > > > For example ServiceContext is created inside the getServiceContext()
> > > method in the ServiceGroupContext class
> > > > then ServiceGroupContext is created inside ConfigurationContext in the
> > > method fillServiceContextAndServiceGroupContext ()
> > > >
> > > > What I really wanted to highlight was, not where the places we do a
> new
> > > XXXContext(), but rather if we wanted to control the creation through a
> > > factory class then all we have to do is to change it there. Now we have
> to
> > > track down all the places we do new XXXContext() if want to control the
> > > creation and we can't avoid to create new type of context, for example
> > > ReplicatedServiceContext without introducing a dependency.
> > > >
> > > > What I would have liked to see is ( if possible) to hide the creation
> of
> > > the context behind a Factory class, so that during creation we could
> serve a
> > > Replicated context instead of a normal context transparently to the
> code.
> > >
> > >
> > > There is another way. We can introduce a 'replicate' method to the
> > > AbstractContext. Each context can override this and have its own
> > > replication logic. A a parent 'replicate' method may recursively call it
> for
> > > all the childs. So even if we want to replicate the whole context
> hierarchy
> > > it will be simple as calling this method from the ConfigurationContext
> > > instance (we may not want to do that always).
> > > BTW is it possible for you to commit the code to some place (scratch?)
> so
> > > that we can see what areas we can help on.
> > >
> > > Chamikara
> > >
> > >
> >
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] Clustering impl using tribes
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi David,
I understand that if we were were trying to put some code that is dependent
on a particular clustering implementation into Axis2, we need to hide that
code. But the situation here is a bit different.
What we introduced was a ClusterManager interface. This will live within
Axis2. Now should the rest of the Axia2 code be completely unaware of this
interface. I think it should not.
In this particular scenario i'm talking about some method of Axis2 Context
classes which can be called for serializing their states (sorry abt calling
it 'replicate' may be we should simply call it 'serializeState'). If
somebody have configured Axis2 to enable clustering and if somebody have
mentioned an ClusterManager implementation in the axis2.xml. Some methods of
it will be also called.
I think introducing a factory to create Contexts will introduce an
unnecessary complexity. Still there may be many other places where we may
directly have to call the methods of the ClusterManager interface.
Chamikara
On 10/23/06, David Illsley <da...@gmail.com> wrote:
>
> Moving to a factory creation style which allows the base Axis2
> implementations to not contain any clustering code sounds simplest and
> most attractive to me.
>
> David
>
> On 21/10/06, Chamikara Jayalath <ch...@gmail.com> wrote:
> > Hi Rajith,
> >
> > Please see my comments below.
> >
> > On 10/20/06, Rajith Attapattu <ra...@gmail.com> wrote:
> > > Deepal,
> > >
> > > Thanks for your answers, I really appreciate it.
> > >
> > > >There is an id associate with ServiceGroupContext , so once you have
> SGC
> > > >from the you can get the service context . Then the id of the SC will
> be
> > > >the name of the corresponding AxisService.
> > > That is what I did so far, but service name is not a unique id.
> > > However can a service by the same name can exist in a diffrent service
> > group ???
> > >
> > > For now I use service group id + service name as a unique key.
> > >
> > > >>How big is the jar ?
> > > Deepal we should not have dependency on tribes as our clustering
> > implementation. So even if it's a samll jar we should decouple the
> > clustering impl from the kernal.
> > > Sanjiva also has an idea of using Richochet in the future, so we
> should be
> > able to implement that without doing too much work.
> > >
> > > >What do you mean by all over th place , as I know all of them are
> > > > created inside instance dispatcher.
> > >
> > >
> > > Sorry if I didn't explain the point properly.
> > >
> > > For example ServiceContext is created inside the getServiceContext()
> > method in the ServiceGroupContext class
> > > then ServiceGroupContext is created inside ConfigurationContext in the
> > method fillServiceContextAndServiceGroupContext ()
> > >
> > > What I really wanted to highlight was, not where the places we do a
> new
> > XXXContext(), but rather if we wanted to control the creation through a
> > factory class then all we have to do is to change it there. Now we have
> to
> > track down all the places we do new XXXContext() if want to control the
> > creation and we can't avoid to create new type of context, for example
> > ReplicatedServiceContext without introducing a dependency.
> > >
> > > What I would have liked to see is ( if possible) to hide the creation
> of
> > the context behind a Factory class, so that during creation we could
> serve a
> > Replicated context instead of a normal context transparently to the
> code.
> >
> >
> > There is another way. We can introduce a 'replicate' method to the
> > AbstractContext. Each context can override this and have its own
> > replication logic. A a parent 'replicate' method may recursively call it
> for
> > all the childs. So even if we want to replicate the whole context
> hierarchy
> > it will be simple as calling this method from the ConfigurationContext
> > instance (we may not want to do that always).
> > BTW is it possible for you to commit the code to some place (scratch?)
> so
> > that we can see what areas we can help on.
> >
> > Chamikara
> >
> >
>
>
> --
> David Illsley - IBM Web Services Development
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [axis2] Clustering impl using tribes
Posted by Rajith Attapattu <ra...@gmail.com>.
Deepal,
Thanks for your answers, I really appreciate it.
>There is an id associate with ServiceGroupContext , so once you have SGC
>from the you can get the service context . Then the id of the SC will be
>the name of the corresponding AxisService.
That is what I did so far, but service name is not a unique id.
However can a service by the same name can exist in a diffrent service group
???
For now I use service group id + service name as a unique key.
>>How big is the jar ?
Deepal we should not have dependency on tribes as our clustering
implementation. So even if it's a samll jar we should decouple the
clustering impl from the kernal.
Sanjiva also has an idea of using Richochet in the future, so we should be
able to implement that without doing too much work.
>What do you mean by all over th place , as I know all of them are
> created inside instance dispatcher.
Sorry if I didn't explain the point properly.
For example ServiceContext is created inside the getServiceContext() method
in the ServiceGroupContext class
then ServiceGroupContext is created inside ConfigurationContext in the
method fillServiceContextAndServiceGroupContext ()
What I really wanted to highlight was, not where the places we do a new
XXXContext(), but rather if we wanted to control the creation through a
factory class then all we have to do is to change it there. Now we have to
track down all the places we do new XXXContext() if want to control the
creation and we can't avoid to create new type of context, for example
ReplicatedServiceContext without introducing a dependency.
What I would have liked to see is ( if possible) to hide the creation of the
context behind a Factory class, so that during creation we could serve a
Replicated context instead of a normal context transparently to the code.
>>We can fix this easily , its a small change :)
great, so the fix is that you create a ServiceGroupContext with the id
before a service context is created ?
How soon can u make this change ?
I can make this change locally if u help me track down the place to do it :)
Thanks,
Rajith
On 10/20/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> Rajith Attapattu wrote:
>
> > Hi All,
> >
> > I have built a clustering prototype for axis2 using tribes. However
> > here are my observations which really concerns me.
> > I slighlty modified the interface proposed by chamikara (modifications
> > are just addition of parameters to the methods) to get this working.
> >
> > The interface is actually a very good abstraction, how ever the
> > existing axis2 architecture falls short of expectation in making it a
> > good fit.
> > Ideas are welcome to improve on this (given that the axis2
> > architecture is static)
> > I have broken them down to practical issues and architectural issues.
> >
> > Architectural concerns which reduce the usability of the proposed
> > Interface
> >
> --------------------------------------------------------------------------------------------------------------
> >
> > A) The Context heirachy has no common interface, therefore we cannot
> > treat both ServiceContext and ServiceGroupContext as the same due to
> > the following reasons
> > 1.) There is no context id associated with ServiceContext,
> > therefore just having the context id as a parameter is not good enough
>
> There is an id associate with ServiceGroupContext , so once you have SGC
> from the you can get the service context . Then the id of the SC will be
> the name of the corresponding AxisService.
>
> >
> > 2.) We cannot use the ReplicatedHashMap provided by Tribes
> > without introducing a dependency to kernal module on Tribes.
>
> How big is the jar ?
>
> > If we had an interface we could have created a
> > ReplicatedServiceContext and ReplicatedServiceGroupContext
> > implementing the interface.
> >
> > B) Even if we had an interface, the creation of Contexts are done all
> > over the place, instead through a Factory class, therefore limiting
> > the possibility of supplying a Replicated context without introducing
> > a hard dependency on tribes to kernal module.
>
> > What do you mean by all over th place , as I know all of them are
> > created inside instance dispatcher.
Sorry if I didn't explain the point properly.
For example ServiceContext is created inside the getServiceContext() method
in the ServiceGroupContext class
then ServiceGroupContext is created inside ConfigurationContext in the
method fillServiceContextAndServiceGroupContext ()
What I really wanted to highlight was, not where the places we do a new
XXXContext(), but rather if we wanted to control the creation through a
factory class then all we have to do is to change it there. Now we have to
track down all the places we do new XXXContext() if want to control the
creation.
What I would have liked to see is ( if possible) to hide the creation of the
context behind a Factory class, so that during creation we could serve a
Replicated context instead of a normal context transparently to the code.
>
> > We have 2 possible solutions to avoid a dependency.
> > 1.) Delegate the setProperty(k,v) & setProperties(map) method to the
> > impl via the interface and then use low level tribes API to do the
> > replication.
> > This is a pain in the ass as we have to manage synchronization
> > manually across the cluster. Reinventing wheel...not in a mood to do
> > so :)
> >
> > 2.) Manage a set of Maps at the implementation level which are wrapped
> > with ReplicatedMap, and then we only need to sync with the maps in the
> > context.
> > This is ugly, but it works with minimal effort.
> >
> >
> > Practical issues
> > -----------------------
> > 1.) The context id for service groups are not set at creation time, so
> > we cannot replicate the creation of a service group context until a
> > context id is set.
> >
> > 2.) A Service context cannot exist without a Service Group context,
> > however before we have a id for service group context a service
> > context is created for the service.
> > So we have to hold on to the service context, until we have a id
> > for service group context, then replicated the group ctx and then the
> > service ctx.
>
> We can fix this easily , its a small change :)
>
> >
> > Any solutions to this problem?
> >
> > Regards,
> >
> > Rajith
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [axis2] Clustering impl using tribes
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Rajith Attapattu wrote:
> Hi All,
>
> I have built a clustering prototype for axis2 using tribes. However
> here are my observations which really concerns me.
> I slighlty modified the interface proposed by chamikara (modifications
> are just addition of parameters to the methods) to get this working.
>
> The interface is actually a very good abstraction, how ever the
> existing axis2 architecture falls short of expectation in making it a
> good fit.
> Ideas are welcome to improve on this (given that the axis2
> architecture is static)
> I have broken them down to practical issues and architectural issues.
>
> Architectural concerns which reduce the usability of the proposed
> Interface
> --------------------------------------------------------------------------------------------------------------
>
> A) The Context heirachy has no common interface, therefore we cannot
> treat both ServiceContext and ServiceGroupContext as the same due to
> the following reasons
> 1.) There is no context id associated with ServiceContext,
> therefore just having the context id as a parameter is not good enough
There is an id associate with ServiceGroupContext , so once you have SGC
from the you can get the service context . Then the id of the SC will be
the name of the corresponding AxisService.
>
> 2.) We cannot use the ReplicatedHashMap provided by Tribes
> without introducing a dependency to kernal module on Tribes.
How big is the jar ?
> If we had an interface we could have created a
> ReplicatedServiceContext and ReplicatedServiceGroupContext
> implementing the interface.
>
> B) Even if we had an interface, the creation of Contexts are done all
> over the place, instead through a Factory class, therefore limiting
> the possibility of supplying a Replicated context without introducing
> a hard dependency on tribes to kernal module.
What do you mean by all over th place , as I know all of them are
created inside instance dispatcher.
>
> We have 2 possible solutions to avoid a dependency.
> 1.) Delegate the setProperty(k,v) & setProperties(map) method to the
> impl via the interface and then use low level tribes API to do the
> replication.
> This is a pain in the ass as we have to manage synchronization
> manually across the cluster. Reinventing wheel...not in a mood to do
> so :)
>
> 2.) Manage a set of Maps at the implementation level which are wrapped
> with ReplicatedMap, and then we only need to sync with the maps in the
> context.
> This is ugly, but it works with minimal effort.
>
>
> Practical issues
> -----------------------
> 1.) The context id for service groups are not set at creation time, so
> we cannot replicate the creation of a service group context until a
> context id is set.
>
> 2.) A Service context cannot exist without a Service Group context,
> however before we have a id for service group context a service
> context is created for the service.
> So we have to hold on to the service context, until we have a id
> for service group context, then replicated the group ctx and then the
> service ctx.
We can fix this easily , its a small change :)
>
> Any solutions to this problem?
>
> Regards,
>
> Rajith
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org