[
https://issues.apache.org/jira/browse/HBASE-23832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102264#comment-17102264
]
Sean Busbey commented on HBASE-23832:
-------------------------------------
we removed and renamed tons of configs in 2.0. IMHO we could just document this
one in renamed list.
http://hbase.apache.org/book.html#upgrade2.0.removed.configs
http://hbase.apache.org/book.html#upgrade2.0.renamed.configs
it looks like in this case we wanted to maintain compatibility for HBase 2, so
I think it'd also be reasonable to do that. then we can remove it for HBase 3
and release note it like we did for all the things we removed from HBase 2.
If we keep it then it would be better if we did the fall back using
{{Configuration.addDeprecation}} so that folks get some warning about the
coming change.
> Old config hbase.hstore.compactionThreshold is ignored
> ------------------------------------------------------
>
> Key: HBASE-23832
> URL: https://issues.apache.org/jira/browse/HBASE-23832
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Anoop Sam John
> Assignee: Sambit Mohapatra
> Priority: Critical
>
> In 2.x we added new name 'hbase.hstore.compaction.min' for this. Still for
> compatibility we allow the old config name and honor that in code
> {code}
> minFilesToCompact = Math.max(2, conf.getInt(HBASE_HSTORE_COMPACTION_MIN_KEY,
> /*old name*/ conf.getInt("hbase.hstore.compactionThreshold", 3)));
> {code}
> But if hbase.hstore.compactionThreshold alone is configured by user, there is
> no impact of that.
> This is because in hbase-default.xml we have the new config with a value of
> 3. So the call conf.getInt(HBASE_HSTORE_COMPACTION_MIN_KEY) always return a
> value 3 even if it is not explicitly configured by customer and instead used
> the old key.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
