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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
