hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17838) Replace fixed Executor Threads with dynamic thread pool
Date Mon, 27 Mar 2017 15:27:41 GMT

    [ 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


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?


> 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

View raw message