[
https://issues.apache.org/jira/browse/HBASE-13729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14573910#comment-14573910
]
Anoop Sam John commented on HBASE-13729:
----------------------------------------
bq.For new deployments this will take the hardcoded defaults which are the same
from hbase-default.xml
Yes.. Good then..
+1. Thanks for the nice catch [~esteban]
BTW I was telling abt below example in hbase-default.xml
{code}
<property>
<name>hbase.hstore.compaction.min</name>
<value>3</value>
<description>The minimum number of StoreFiles which must be eligible for
compaction before
compaction can run. The goal of tuning hbase.hstore.compaction.min is to
avoid ending up with
too many tiny StoreFiles to compact. Setting this value to 2 would cause
a minor compaction
each time you have two StoreFiles in a Store, and this is probably not
appropriate. If you
set this value too high, all the other values will need to be adjusted
accordingly. For most
cases, the default value is appropriate. In previous versions of HBase,
the parameter
hbase.hstore.compaction.min was named
hbase.hstore.compactionThreshold.</description>
</property>
<property>
<name>hbase.hstore.compactionThreshold</name>
<value>3</value>
<description> If more than this number of StoreFiles exist in any one Store
(one StoreFile is written per flush of MemStore), a compaction is run to
rewrite all
StoreFiles into a single StoreFile. Larger values delay compaction, but
when compaction does
occur, it takes longer to complete.</description>
</property>
{code}
Also we need to make an agreement that when we can remove a deprecated config
(like Java API).. We seems not at all removing the old deprecated configs.
What do you say [~stack]
> Old hbase.regionserver.global.memstore.upperLimit and lowerLimit properties
> are ignored if present
> --------------------------------------------------------------------------------------------------
>
> Key: HBASE-13729
> URL: https://issues.apache.org/jira/browse/HBASE-13729
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 2.0.0, 1.0.1, 1.1.0
> Reporter: Esteban Gutierrez
> Assignee: Esteban Gutierrez
> Priority: Critical
> Attachments:
> 0001-HBASE-13729-Old-hbase.regionserver.global.memstore.u.patch,
> HBASE-13729.2.patch, HBASE-13729.3.patch, HBASE-13729.4.patch
>
>
> If hbase.regionserver.global.memstore.upperLimit or lowerLimit are present we
> should use them instead of hbase.regionserver.global.memstore.size or
> hbase.regionserver.global.memstore.size.lower.limit respectively. The current
> implementation of HeapMemorySizeUtil.getGlobalMemStorePercent() and
> getGlobalMemStoreLowerMark() asumes that if the new properties are not
> defined then we should use the old configurations, however the new properties
> are defined in hbase-default.xml which makes the old configuration names
> useless and this has a direct impact when doing a rolling upgrade and
> hbase-site.xml hasn't been changed to handle the new property names
> exclusively.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
