[
https://issues.apache.org/jira/browse/HDFS-9642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093474#comment-15093474
]
Kai Zheng commented on HDFS-9642:
---------------------------------
Looks like creating the unused thread pool (with core thread 1, setting
{{allowsCoreThreadTimeOut}} true) for replication won't incur much overhead,
but creating it using the default value may be problematic. It would still rely
on a configuration value to calculate the thread pool size as current code
does, since it's not clear how many read tasks will happen in a client. Suggest
changing the current configuration item {{THREADPOOL_SIZE_KEY}} to something
like {{THREADPOOL_SIZE_FACTOR}}, then the pool size can be calculated as:
{{THREADPOOL_SIZE_FACTOR * BLOCKS_IN_ONE_GROUP}}. But then how about changing
to use other EC policy with different schema? Need some discussion.
> Create reader threads pool on demand according to erasure coding policy
> -----------------------------------------------------------------------
>
> Key: HDFS-9642
> URL: https://issues.apache.org/jira/browse/HDFS-9642
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Kai Zheng
> Assignee: Kai Zheng
>
> While investigating some issue it was noticed in {{DFSClient}},
> {{STRIPED_READ_THREAD_POOL}} will be always created during initialization and
> by default regardless the used erasure coding policy it uses the value *18*.
> This suggests:
> * Create the thread pool on demand only in striping case.
> * When create the pool, use a good value respecting the used erasure coding
> policy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
