[GitHub] [gobblin] phet commented on a change in pull request #3427: [GOBBLIN-1575] make a copy of helix manager, so that each job can keep using it with…

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

phet commented on a change in pull request #3427:
URL: https://github.com/apache/gobblin/pull/3427#discussion_r750676638



##########
File path: gobblin-cluster/src/main/java/org/apache/gobblin/cluster/HelixRetriggeringJobCallable.java
##########
@@ -161,6 +170,10 @@ public Void call() throws JobException {
     }
 
     try {
+      this.jobHelixManager.connect();
+      if (this.taskDriverHelixManager.isPresent()) {
+        this.taskDriverHelixManager.get().connect();
+      }

Review comment:
       again... don't these belong prior to and outside the `try` (technically even w/ each its own separate, nested `try` block)?

##########
File path: gobblin-cluster/src/main/java/org/apache/gobblin/cluster/GobblinHelixJobTask.java
##########
@@ -203,6 +209,7 @@ public TaskResult run() {
       return new TaskResult(TaskResult.Status.FAILED, "Exception occurred for job " + planningJobId + ":" + ExceptionUtils
           .getFullStackTrace(e));
     } finally {
+      this.jobHelixManager.disconnect();

Review comment:
       formatting is a bit hard to discern (in the PR viewer), but is this the `finally` of the `try` block where the `.connect()` call is the first statement?  if so, shouldn't we either move the `.connect()` directly prior to the `try`, or else begin another `try` right after the `connect()`?

##########
File path: gobblin-cluster/src/main/java/org/apache/gobblin/cluster/HelixRetriggeringJobCallable.java
##########
@@ -126,8 +126,17 @@ public HelixRetriggeringJobCallable(
     this.planningJobLauncherMetrics = planningJobLauncherMetrics;
     this.helixMetrics = helixMetrics;
     this.appWorkDir = appWorkDir;
-    this.jobHelixManager = jobHelixManager;
-    this.taskDriverHelixManager = taskDriverHelixManager;
+
+    // make a copy of helix managers, so that each job can keep using it without worrying about disconnect from the GobblinClusterManager where they are created
+    this.jobHelixManager = GobblinHelixMultiManager.buildHelixManager(ConfigUtils.propertiesToConfig(sysProps),
+        sysProps.getProperty(GobblinClusterConfigurationKeys.ZK_CONNECTION_STRING_KEY),
+        GobblinClusterConfigurationKeys.HELIX_CLUSTER_NAME_KEY, jobHelixManager.getInstanceType());
+
+    this.taskDriverHelixManager = taskDriverHelixManager.map(
+        helixManager -> GobblinHelixMultiManager.buildHelixManager(ConfigUtils.propertiesToConfig(sysProps),
+            sysProps.getProperty(GobblinClusterConfigurationKeys.ZK_CONNECTION_STRING_KEY),
+            GobblinClusterConfigurationKeys.TASK_DRIVER_CLUSTER_NAME_KEY, helixManager.getInstanceType()));
+

Review comment:
       when I saw this above, I was wondering whether it shouldn't be abstracted into a utility... now seeing it again (twice!), I really think so.  any impediment to doing so?

##########
File path: gobblin-cluster/src/main/java/org/apache/gobblin/cluster/HelixRetriggeringJobCallable.java
##########
@@ -172,7 +185,10 @@ public Void call() throws JobException {
       if (deleteJobWhenException) {
         deleteJobSpec();
       }
-      throw e;
+      throw new JobException(e.getMessage());
+    } finally {
+      this.jobHelixManager.disconnect();
+      this.taskDriverHelixManager.ifPresent(HelixManager::disconnect);

Review comment:
       I believe these belong in separate `try ... finally` blocks (and, per nesting, `disconnect()` (i.e. closing/finalization) should be in *reverse* order of `connect()` (initialization)




-- 
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.

To unsubscribe, e-mail: dev-unsubscribe@gobblin.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org