[
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)
