Hi Lahiru and Imesh, Thanks a lot for the input.
What I do here is locking only the relevant sub tree of the complete Topology tree, as locking the whole tree is rather inefficient. For an example, when a MemberActivated event is received, we have the cluster id of the cluster that particular member belongs to. IMHO, we only need to acquire the write lock for that cluster , and do not need the lock for complete Topology tree. Therefore, any other thread which needs to do another operation on a separate sub tree (for an example, deploy a new service, etc.) can do that concurrently. On Sun, Oct 5, 2014 at 12:20 AM, Lahiru Sandaruwan <lahi...@wso2.com> wrote: > Hi Isuru, > > Looks like a good move to improve the efficiency, > > On Fri, Oct 3, 2014 at 3:05 PM, Isuru Haththotuwa <isu...@apache.org> > wrote: > >> I did the initial changes, at the testing phase now. For an example, if >> we need to add a new Service, we do not need to lock everything now. We an >> only acquire the write lock on Services, and add the Service. >> > > Service can be an element of a group or an app. So shouldn't we lock > complete application if we add/modify a service? Otherwise a different > thread might change parents/relationships otherwise. > AFAIK a Service gets created when we deploy a cartridge. An application/Group can refer a service. In the case of modifying an Application, we do need to lock the relevant clusters that belong to that Application. I implemented that. > > So generally i think we can bring down the locking level to Application, > but not the services. Also if we need to read any part, we have to get the > read lock for the whole topology, such that the receiver get a particular > snapshot of the topology as Imesh also mentioned. > If we need to lock the complete Topology, we can still do that, such as in a Complete Topology event. But IMHO, if we know the exact part (a particular Cluster, etc.) that we need to read/write, we do not need to lock the whole Topology. > > Thanks. > > If we need to modify a particular Service, can read lock the Services and >> acquire the write lock on the relevant Service and do the modification. >> > This support is there for Services, Cluster and Applications. >> > >> On Wed, Oct 1, 2014 at 9:27 PM, Manula Chathurika Thantriwatte < >> manu...@wso2.com> wrote: >> >>> Hi Isuru, >>> >>> +1 for the hierarchical locking approach. Using hierarchical locking we >>> can have more benefits [1]. >>> >>> [1] >>> http://synapticnulship.com/blog/2013/03/08/comparison-chainlocker-vs-heirarchical-mutexes/ >>> >>> >>> On Wed, Oct 1, 2014 at 7:46 PM, Isuru Haththotuwa <isu...@apache.org> >>> wrote: >>> >>>> Hi Devs, >>>> >>>> In the current Topology implementation, we acquire read/write locks on >>>> Topology from the root level itself. For an example, if we need to modify a >>>> single Cluster object, we still need to acquire a write lock from the >>>> Topology root level. But, this is a costly operation. Specially, with >>>> Service Grouping changes, we would need to traverse through an Application. >>>> Since an Application can be a recursive structure, it can be a time >>>> consuming operation. in such a scenario, if we are to lock the whole >>>> Topology, there will be many threads waiting on that lock. >>>> >>>> As a solution, I think we can use hierarchical locking [1]. For an >>>> example, when you need to obtain the write lock for a particular >>>> Application, you do not need to lock the whole tree, but can lock only that >>>> Application itself. However, still we need to get the read locks for the >>>> parents. >>>> >>>> A separate Lock tree will be maintained for the Topology. >>>> >>>> Please share your feedback. >>>> >>>> [1]. >>>> http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2008/0801/071201hs01/071201hs01.html >>>> >>>> -- >>>> Thanks and Regards, >>>> >>>> Isuru H. >>>> +94 716 358 048* <http://wso2.com/>* >>>> >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Manula Chathurika Thantriwatte >>> Software Engineer >>> WSO2 Inc. : http://wso2.com >>> lean . enterprise . middleware >>> >>> email : manu...@wso2.com / man...@apache.org >>> phone : +94 772492511 >>> blog : http://manulachathurika.blogspot.com/ >>> >>> -- >>> <http://manulachathurika.blogspot.com/> >>> Thanks and Regards, >>> >>> Isuru H. >>> <http://manulachathurika.blogspot.com/> >>> +94 716 358 048 <http://manulachathurika.blogspot.com/>* >>> <http://wso2.com/>* >>> >>> >>> * <http://wso2.com/>* >>> >>> >>> > > > -- > -- > Lahiru Sandaruwan > Committer and PMC member, Apache Stratos, > Senior Software Engineer, > WSO2 Inc., http://wso2.com > lean.enterprise.middleware > > email: lahi...@wso2.com cell: (+94) 773 325 954 > blog: http://lahiruwrites.blogspot.com/ > twitter: http://twitter.com/lahirus > linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 > > -- > <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> > Thanks and Regards, > > Isuru H. > <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> > +94 716 358 048 <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146>* > <http://wso2.com/>* > > > * <http://wso2.com/>* > > >
