axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: [axis2] Clustering impl using tribes
Date Fri, 20 Oct 2006 15:08:24 GMT
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 <deepal@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
>
>

Mime
View raw message