Chamikara
On 10/25/06, Rajith Attapattu <[EMAIL PROTECTED]> 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,
RajithOn 10/24/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:Hi David,
It was discussed here.
http://marc.theaimsgroup.com/?t=115522886000003&r=1&w=2
ChamikaraOn 10/24/06, David Illsley <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]> wrote:
> > > Hi Rajith,
> > >
> > > Please see my comments below.
> > >
> > > On 10/20/06, Rajith Attapattu < [EMAIL PROTECTED]> 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:
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
