stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <im...@apache.org>
Subject Re: [Discuss] Hierarchical Locking for Topology
Date Mon, 06 Oct 2014 05:20:34 GMT
Great! Thanks for the clarification Isuru!

Yes I agree, I think what we can do is, identify the sub trees that will
not break the consistency of the data structure and manage locks at those
sub tree level.

Thanks

On Sun, Oct 5, 2014 at 8:07 PM, Isuru Haththotuwa <isuruh@apache.org> wrote:

> 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 <lahirus@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 <isuruh@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 <
>>> manulac@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 <isuruh@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 : manulac@wso2.com / manula@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: lahirus@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/>*
>>
>>
>>


-- 
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos

Mime
View raw message