jiajunwang commented on a change in pull request #973:
URL: https://github.com/apache/helix/pull/973#discussion_r420325192
##########
File path:
helix-core/src/main/java/org/apache/helix/task/TaskStateModelFactory.java
##########
@@ -81,6 +79,12 @@ public Thread newThread(Runnable r) {
@Override
public TaskStateModel createNewStateModel(String resourceName, String
partitionKey) {
+ if (_taskExecutor == null) {
+ int taskThreadPoolSize = getTaskThreadPoolSize();
+ updateLiveInstanceWithThreadPoolSize(taskThreadPoolSize);
Review comment:
1. why we have to relies on the HelixManager to query for the config?
You can use data accessor whenever it is requried. But if we don't even have
the cluster/zk information, then it is not possible. This is one of the cons
(or limitations) that we rely on ZK to pass the configuration.
2. The controller needs to know the real capacity otherwise how it ensures
the assigned tasks fit the instance's capacity? I think this is the purpose of
this design, no?
3. Alternatively, you can report the accepted capacity without really
applying it to any executor. I mean, when liveinstance is created, put the
capacity there. But at that moment, there is no real executor exists. Then when
we create the executor, we apply for exactly the same number there.
To be clear, this is not a preferred design. In this way, the
CURRENT_THREAD_POOL_SIZE becomes meaningless. But that is the only thing I can
think of now.
----------------------------------------------------------------
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]
