+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 <[email protected]> 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: [email protected] blog: http://lahiruwrites.blogspot.com/ linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
