axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <chamikar...@gmail.com>
Subject Re: [axis2] Clustering impl using tribes
Date Wed, 25 Oct 2006 04:07:01 GMT
OK. Waiting for it :-)

Chamikara


On 10/25/06, Rajith Attapattu <rajith77@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 <chamikaramj@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 <chamikaramj@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
> > >
> > >
> >
>

Mime
View raw message