[
https://issues.apache.org/jira/browse/HBASE-17838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943461#comment-15943461
]
stack commented on HBASE-17838:
-------------------------------
bq. the default logic is somehow dynamic in the number of threads allocated, is
there any advantage of replacing it other than having ThreadPoolExecutor as a
common implementation?
I've not done the study to see how worker thread count currently changes over
life of a running procedure engine; I thought it constant?
bq. the default implementation uses a custom configurable logic to create new
threads (definition of stuck threads, ratio of stuck threads etc). I think it
would be quite hacky to put the same logic to a custom threadpoolexecutor
Probably
bq. in the current design, executer worker threads are polling the scheduler to
gather tasks, what I tried to maintain in this patch, but I would feel more
natural to make scheduler submit tasks to the executor.
Yes. For an executor, submit would make more sense. That'd be a radical change
though.
bq. In sum: Is this a good direction at all?
Doesn't seem so, not until more experience with the procedure engine. Want to
leave this aside then [~gubjanos]? Or just close it since you've done the study
and we can mark it off from the list in the parent issue?
Thanks.
> Replace fixed Executor Threads with dynamic thread pool
> --------------------------------------------------------
>
> Key: HBASE-17838
> URL: https://issues.apache.org/jira/browse/HBASE-17838
> Project: HBase
> Issue Type: Sub-task
> Components: Performance, proc-v2
> Reporter: Janos Gub
> Assignee: Janos Gub
> Fix For: 2.0.0
>
> Attachments: initial.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
