[GitHub] [fluo] keith-turner commented on a change in pull request #1088: Use LeaderLatch to determine if oracle exists

[GitBox <gi...@apache.org>]

keith-turner commented on a change in pull request #1088: Use LeaderLatch to determine if oracle exists
URL: https://github.com/apache/fluo/pull/1088#discussion_r388578931
 
 

 ##########
 File path: modules/core/src/main/java/org/apache/fluo/core/client/FluoAdminImpl.java
 ##########
 @@ -505,30 +505,28 @@ private String getJarsFromClasspath() {
   }
 
   public static boolean oracleExists(CuratorFramework curator) {
-    try {
-      return curator.checkExists().forPath(ZookeeperPath.ORACLE_SERVER) != null
-          && !curator.getChildren().forPath(ZookeeperPath.ORACLE_SERVER).isEmpty();
-    } catch (Exception e) {
-      throw new RuntimeException(e);
-    }
+    return numOracles(curator) > 0;
   }
 
   public boolean oracleExists() {
     return oracleExists(getAppCurator());
   }
 
-  public int numOracles() {
-    CuratorFramework curator = getAppCurator();
-    if (oracleExists(curator)) {
-      try {
+  public static int numOracles(CuratorFramework curator) {
+    int numOracles = 0;
+    try {
+      if (curator.checkExists().forPath(ZookeeperPath.ORACLE_SERVER) != null) {
 
 Review comment:
   The pattern of checking for existence before the operation has a race condition.  Its possible that the node is deleted after the existence check but before the operation.
   
   I took a look at the code and its possible this existence check may not be needed.  The following code for `getParticipants()` calls `getSortedChildren()`
   
   https://github.com/apache/curator/blob/959c1ca34f6ebcb11370180dfafbd8e85320dcd2/curator-recipes/src/main/java/org/apache/curator/framework/recipes/leader/LeaderLatch.java#L448
   
   and `getSortedChildren()` seems like it may return empty list when the node does not exists.
   
   https://github.com/apache/curator/blob/959c1ca34f6ebcb11370180dfafbd8e85320dcd2/curator-recipes/src/main/java/org/apache/curator/framework/recipes/locks/LockInternals.java#L172
   
   Not sure if the version of Curator used by Fluo does this.   
   
   When dealing with ZK the pattern of trying the operation and catching NoNodeException is better than checking for existence  before the operation because it avoids race conditions. 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services