Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 28 Jan 2014 02:13:44 +0000 (UTC)
From: "chunhui shen (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12507918.1305920476808.23293.1390875224434@arcas>
In-Reply-To: <JIRA.12507918.1305920476808@arcas>
References: <JIRA.12507918.1305920476808@arcas>
Subject: [jira] [Commented] (HBASE-3909) Add dynamic config
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883662#comment-13883662 ] 

chunhui shen commented on HBASE-3909:
-------------------------------------

Throw some potential problems I think:
1.As the implementation of patch, only allow some configuration to reset the value after reloading. It means Administrator should remember the configurations which could be reloaded dynamically. 
I think it will puzzle the user whether the configuraion value he expected is reset.

2.Through the Configuration Observer, will  the reloaded value take affect  properly? At least, resetting the compaction threads number is possible to be not expected on the patch.  For example,  decreasing the CorePoolSize of thread pool will not decrease the number of running thread until the queue of thread pool is empty and the thread is idle for some time. If user want to limit the IO caused by compaction through decreasing the compaction threads number dynamically, but compaction request is always being produced in real cluster, it means the compaction thread won't be idle, then the running compaction thread won't be decreased.

3.Is it any concurrent risk when reloading the config? A thread may get the old value and new value for the same config when running. Of course, this could be guaranteed in Configuration Observer, but seems not easy.


> Add dynamic config
> ------------------
>
>                 Key: HBASE-3909
>                 URL: https://issues.apache.org/jira/browse/HBASE-3909
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: stack
>            Assignee: Subbu M Iyer
>         Attachments: 3909-102812.patch, 3909-102912.patch, 3909-v1.patch, 3909.v1, 3909_090712-2.patch, HBASE-3909-backport-from-fb-for-trunk-2.patch, HBASE-3909-backport-from-fb-for-trunk.patch, HBase Cluster Config Details.xlsx, patch-v2.patch, testMasterNoCluster.stack
>
>
> I'm sure this issue exists already, at least as part of the discussion around making online schema edits possible, but no hard this having its own issue.  Ted started a conversation on this topic up on dev and Todd suggested we lookd at how Hadoop did it over in HADOOP-7001


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)