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 wrote:
> +1. AFAIU, we can have the sam
+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 wrote:
> +1. With a complications of grouping structure, this
+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
wrote:
> Hi All,
>
> Since we are frequently updating the clusterMonit
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 thing
