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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
