NealSun96 commented on a change in pull request #973:
URL: https://github.com/apache/helix/pull/973#discussion_r419710771
##########
File path:
helix-core/src/main/java/org/apache/helix/task/TaskStateModelFactory.java
##########
@@ -102,4 +107,36 @@ public boolean isShutdown() {
public boolean isTerminated() {
return _taskExecutor.isTerminated();
}
+
+ /*
+ * Get target thread pool size from InstanceConfig first; if that fails, get
it from
+ * ClusterConfig; if that fails, fall back to the default value.
+ */
+ private static int getTaskThreadPoolSize(HelixManager manager) {
+ ConfigAccessor configAccessor = manager.getConfigAccessor();
+ // Check instance config first for thread pool size
+ InstanceConfig instanceConfig =
+ configAccessor.getInstanceConfig(manager.getClusterName(),
manager.getInstanceName());
+ if (instanceConfig != null) {
Review comment:
So the context has changed, and what I said earlier is no longer valid.
Please take a look if you want to further this discussion:
1. Thread pool creation is now after HelixManager connection, which means
`InstanceConfig` and `ClusterConfig` are expected to exist. It should be
treated as an error if they don't exist.
2. I verified with test cases and believe that an earlier comment made by
@narendly is incorrect: if `InstanceConfig` or `ClusterConfig` doesn't exist,
`getInstanceConfig()`/`getClusterConfig()` will throw an HelixException because
`isInstanceSetup()`/`isClusterSetup()` will fail.
Here are the implications of these two points:
With the current design as shown here, if `InstanceConfig`/`ClusterConfig`
doesn't exist, the attempt to create a thread pool will result an
HelixException. I believe it's fine to **not** catch the exception and let it
propagate up, because if `InstanceConfig`/`ClusterConfig` doesn't exist, it's
an erroneous state. This aligns with what @jiajunwang is saying, and is the
current design as we see it.
Alternatively, we can catch the HelixException, log it, and use the default
value (this is @narendly 's idea).
I'm leaning towards the current design (let HelixException propagate upwards
if configs don't exist). Anyone has a different opinion?
----------------------------------------------------------------
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:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
