[
https://issues.apache.org/jira/browse/HBASE-24750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated HBASE-24750:
---------------------------------
Description:
Currently, we have majority Executor services using guava's
ThreadFactoryBuilder while creating fixed size thread pool. There are some
executors using our internal hbase-common's Threads class which provides util
methods for creating thread factory.
Although there is no perf impact, we should let all Executors start using our
internal library for using ThreadFactory rather than having external guava
dependency (which is nothing more than a builder class). We might have to add a
couple more arguments to support full fledged ThreadFactory, but let's do it
and stop using guava's builder class.
Update:
Based on the consensus, we should use only guava library and retire our
internal code which maintains ThreadFactory creation.
was:
Currently, we have majority Executor services using guava's
ThreadFactoryBuilder while creating fixed size thread pool. There are some
executors using our internal hbase-common's Threads class which provides util
methods for creating thread factory.
Although there is no perf impact, we should let all Executors start using our
internal library for using ThreadFactory rather than having external guava
dependency (which is nothing more than a builder class). We might have to add a
couple more arguments to support full fledged ThreadFactory, but let's do it
and stop using guava's builder class.
> All executor service should start using guava ThreadFactory
> -----------------------------------------------------------
>
> Key: HBASE-24750
> URL: https://issues.apache.org/jira/browse/HBASE-24750
> Project: HBase
> Issue Type: Improvement
> Reporter: Viraj Jasani
> Assignee: Viraj Jasani
> Priority: Major
>
> Currently, we have majority Executor services using guava's
> ThreadFactoryBuilder while creating fixed size thread pool. There are some
> executors using our internal hbase-common's Threads class which provides util
> methods for creating thread factory.
> Although there is no perf impact, we should let all Executors start using our
> internal library for using ThreadFactory rather than having external guava
> dependency (which is nothing more than a builder class). We might have to add
> a couple more arguments to support full fledged ThreadFactory, but let's do
> it and stop using guava's builder class.
> Update:
> Based on the consensus, we should use only guava library and retire our
> internal code which maintains ThreadFactory creation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
