This is great. Let's finalize the code from your side and mine. Then we can merge the code and have a code review and QA.
Thank you & Regards, Amal. On Saturday, May 24, 2014, Shazni Nazeer <[email protected]> wrote: > As discussed offline, added service lookups for CoordinatedActivity in the org.wso2.carbon.core.internal.CarbonCoreServiceComponent and used setter methods to add the different coordinated activities into a list in the org.wso2.carbon.core.internal.CarbonCoreDataHolder. Therefore the above mentioned DataHolder is not used directly and private package is not used. > > With this change, I checked the cache invalidation in a GREG cluster and it works perfectly. When a coordinator goes down, another node immediately becomes coordinator and the cache invalidation works thereafter too. > > Shazni Nazeer > > Senior Software Engineer > > Mob : +94 715 440 607 > LinkedIn : http://lk.linkedin.com/in/shazninazeer > Blog : http://shazninazeer.blogspot.com > > On Fri, May 23, 2014 at 4:47 PM, Afkham Azeez <[email protected]> wrote: > > > > On Fri, May 23, 2014 at 3:25 PM, Shazni Nazeer <[email protected]> wrote: > > Hi All, > > With the above mentioned code block in HazelcastClusteringAgent and adding List<CoordinatedActivity> to the org.wso2.carbon.clustering.internal.DataHolder (which isn't yet implemented), I could get the cache invalidation work properly in a GREG cluster in two domains. I also could check when the coordinator goes down, another node becomes the coordinator with the above code block mentioned by Azeez. The coordinated activity also needs to be added when the CacheInvalidationPublisher is created, which will eventually be added to List<CoordinatedActivity> in the DataHolder. > > @Azeez : The org.wso2.carbon.clustering.internal.DataHolder is an internal package and is not getting exported. > > internal packages are not supposed to be exported. Those are private packages that are visible only within the scope of the bundle. > > > Above code block uses it. I could only get this to work by exporting this package. > How can we cope up with this? > > > Shazni Nazeer > > Senior Software Engineer > > Mob : +94 715 440 607 > LinkedIn : http://lk.linkedin.com/in/shazninazeer > Blog : http://shazninazeer.blogspot.com > > On Wed, May 21, 2014 at 8:35 PM, Afkham Azeez <[email protected]> wrote: > > When clustering is initialized, it spawns a thread, which tries to acquire the coordinator lock. The relevant code segment from HazelcastClusteringAgent is as follows: > // Try to acquire the coordinator lock for the cluster > new Thread("cluster-coordinator") { > @Override > public void run() { > hazelcastInstance.getLock("$$cluster#coordinator$#lock").lock(); // code will block here until lock is acquired > isCoordinator = true; > logger.info("Local member is the coordinator"); > // Notify all OSGi services which are waiting for this member to become the coordinator > List<CoordinatedActivity> coordinatedActivities = DataHolder.getInstance().getCoordinatedActivities(); > for (CoordinatedActivity coordinatedActivity : coordinatedActivities) { > coordinatedActivity.execute(); > } > } > }.start(); > > Pay special at -- Thank you & Best regards, *Amal Gunatilake* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
