You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Reka Thirunavukkarasu <re...@wso2.com> on 2014/12/02 18:40:13 UTC
Locking support for ClusterMonitors while dynamically updating Data structure
Hi All,
Since we are frequently updating the clusterMonitors with dynamic
information while drools are getting executed or while a clusterInstance is
getting added, it would be better to have locking support and
proper synchronization before updating these dynamic information. There
are few things as below that we may need to consider before designing
locking for ClusterMonitor.
- Drools usually take time to execute. At that time, if we take the lock,
then other dynamic updates need to wait until drools are getting executed.
It will be blocking for stats updates and etc.
- Drools can't take the partially updated data structure to evaluate. It
should take the latest fully updated data structure.
- We update the CEP stats dynamically to ClusterMonitor without taking any
locks
- CreatedInstance in the ClusterMonitor can be called by several other
threads. It requires synchronisation. GroupMonitor will also ask
ClusterMonitor to create instance based on the scaling decision.
If you have any better suggestion to implement locking support in
ClusterMonitor, please share your suggestions. In the mean while, i will
also go through further and try to find a way to handle it.
Thanks,
Reka
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: Locking support for ClusterMonitors while dynamically updating
Data structure
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Reka,
+1 for introducing a locking mechanism.
Can we first have a look at the threading model we have here, which threads
are accessing the cluster monitor and who execute read/write operations?
Thanks
On Wed, Dec 3, 2014 at 9:57 AM, Isuru Haththotuwa <is...@apache.org> wrote:
> +1. AFAIU, we can have the same read/write lock that we have in Topology
> and Application models, where multiple reads are possible at one time, but
> only can be updated by one thread.
>
> On Tue, Dec 2, 2014 at 11:29 PM, Lahiru Sandaruwan <la...@wso2.com>
> wrote:
>
>> +1. With a complications of grouping structure, this would be a good
>> improvement.
>>
>> For most of the occasions, read lock would be enough for drools file
>> usage...
>>
>> Thanks.
>>
>>
>> On Tue, Dec 2, 2014 at 11:10 PM, Reka Thirunavukkarasu <re...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> Since we are frequently updating the clusterMonitors with dynamic
>>> information while drools are getting executed or while a clusterInstance is
>>> getting added, it would be better to have locking support and
>>> proper synchronization before updating these dynamic information. There
>>> are few things as below that we may need to consider before designing
>>> locking for ClusterMonitor.
>>>
>>> - Drools usually take time to execute. At that time, if we take the
>>> lock, then other dynamic updates need to wait until drools are getting
>>> executed. It will be blocking for stats updates and etc.
>>>
>>> - Drools can't take the partially updated data structure to evaluate. It
>>> should take the latest fully updated data structure.
>>>
>>> - We update the CEP stats dynamically to ClusterMonitor without taking
>>> any locks
>>>
>>> - CreatedInstance in the ClusterMonitor can be called by several other
>>> threads. It requires synchronisation. GroupMonitor will also ask
>>> ClusterMonitor to create instance based on the scaling decision.
>>>
>>> If you have any better suggestion to implement locking support in
>>> ClusterMonitor, please share your suggestions. In the mean while, i will
>>> also go through further and try to find a way to handle it.
>>>
>>>
>>> Thanks,
>>> Reka
>>>
>>> --
>>> Reka Thirunavukkarasu
>>> Senior Software Engineer,
>>> WSO2, Inc.:http://wso2.com,
>>> Mobile: +94776442007
>>>
>>>
>>>
>>
>>
>> --
>> --
>> Lahiru Sandaruwan
>> Committer and PMC member, Apache Stratos,
>> Senior Software Engineer,
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>> linked-in:
>> http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>> --
>> <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
Re: Locking support for ClusterMonitors while dynamically updating
Data structure
Posted by Isuru Haththotuwa <is...@apache.org>.
+1. AFAIU, we can have the same read/write lock that we have in Topology
and Application models, where multiple reads are possible at one time, but
only can be updated by one thread.
On Tue, Dec 2, 2014 at 11:29 PM, Lahiru Sandaruwan <la...@wso2.com> wrote:
> +1. With a complications of grouping structure, this would be a good
> improvement.
>
> For most of the occasions, read lock would be enough for drools file
> usage...
>
> Thanks.
>
>
> On Tue, Dec 2, 2014 at 11:10 PM, Reka Thirunavukkarasu <re...@wso2.com>
> wrote:
>
>> Hi All,
>>
>> Since we are frequently updating the clusterMonitors with dynamic
>> information while drools are getting executed or while a clusterInstance is
>> getting added, it would be better to have locking support and
>> proper synchronization before updating these dynamic information. There
>> are few things as below that we may need to consider before designing
>> locking for ClusterMonitor.
>>
>> - Drools usually take time to execute. At that time, if we take the lock,
>> then other dynamic updates need to wait until drools are getting executed.
>> It will be blocking for stats updates and etc.
>>
>> - Drools can't take the partially updated data structure to evaluate. It
>> should take the latest fully updated data structure.
>>
>> - We update the CEP stats dynamically to ClusterMonitor without taking
>> any locks
>>
>> - CreatedInstance in the ClusterMonitor can be called by several other
>> threads. It requires synchronisation. GroupMonitor will also ask
>> ClusterMonitor to create instance based on the scaling decision.
>>
>> If you have any better suggestion to implement locking support in
>> ClusterMonitor, please share your suggestions. In the mean while, i will
>> also go through further and try to find a way to handle it.
>>
>>
>> Thanks,
>> Reka
>>
>> --
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>> Mobile: +94776442007
>>
>>
>>
>
>
> --
> --
> Lahiru Sandaruwan
> Committer and PMC member, Apache Stratos,
> Senior Software Engineer,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>
Re: Locking support for ClusterMonitors while dynamically updating
Data structure
Posted by Lahiru Sandaruwan <la...@wso2.com>.
+1. With a complications of grouping structure, this would be a good
improvement.
For most of the occasions, read lock would be enough for drools file
usage...
Thanks.
On Tue, Dec 2, 2014 at 11:10 PM, Reka Thirunavukkarasu <re...@wso2.com>
wrote:
> Hi All,
>
> Since we are frequently updating the clusterMonitors with dynamic
> information while drools are getting executed or while a clusterInstance is
> getting added, it would be better to have locking support and
> proper synchronization before updating these dynamic information. There
> are few things as below that we may need to consider before designing
> locking for ClusterMonitor.
>
> - Drools usually take time to execute. At that time, if we take the lock,
> then other dynamic updates need to wait until drools are getting executed.
> It will be blocking for stats updates and etc.
>
> - Drools can't take the partially updated data structure to evaluate. It
> should take the latest fully updated data structure.
>
> - We update the CEP stats dynamically to ClusterMonitor without taking any
> locks
>
> - CreatedInstance in the ClusterMonitor can be called by several other
> threads. It requires synchronisation. GroupMonitor will also ask
> ClusterMonitor to create instance based on the scaling decision.
>
> If you have any better suggestion to implement locking support in
> ClusterMonitor, please share your suggestions. In the mean while, i will
> also go through further and try to find a way to handle it.
>
>
> Thanks,
> Reka
>
> --
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146