hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5925) Issue with only using the old config param hbase.hstore.compactionThreshold but not the corresponding new one
Date Tue, 08 May 2012 08:34:04 GMT

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

Anoop Sam John commented on HBASE-5925:
---------------------------------------

@Stack

I have gone through the patch for HBASE-3272
{code}
-      conf.getInt("hbase.hstore.blockingStoreFiles", -1);
+      conf.getInt("hbase.hstore.blockingStoreFiles", 7);
     if (this.blockingStoreFilesNumber == -1) {
       this.blockingStoreFilesNumber = 1 +
         conf.getInt("hbase.hstore.compactionThreshold", 3);
{code}
As per this change the default value for the hbase.hstore.blockingStoreFiles is been considered
as 7. Previously it was like 1+ value for hbase.hstore.compactionThreshold
[See the code below which checks if (this.blockingStoreFilesNumber == -1)]

I think now after the patch for HBASE-3272 this if check may not be needed
{code}
if (this.blockingStoreFilesNumber == -1) {
       this.blockingStoreFilesNumber = 1 +
         conf.getInt("hbase.hstore.compactionThreshold", 3);
{code}

I didnt know about this patch based change and when seen this piece of code with if check
for -1, it looks like if explicitely -1 is configured, it will take the blockingStoreFilesNumber
 as 1+ value of hbase.hstore.compactionThreshold. I thought that this was intentionally given..
What this defect tells is as we later changed the config name for hbase.hstore.compactionThreshold
to hbase.hstore.compaction.min, we need to consider that value here with precedence over the
value for hbase.hstore.compactionThreshold

Hope the desc is clear to you now...  Any way now that is not needed.. What I think is that
we can remove the code 
{code}
if (this.blockingStoreFilesNumber == -1) {
       this.blockingStoreFilesNumber = 1 +
         conf.getInt("hbase.hstore.compactionThreshold", 3);
{code}
which might confuse us..  What do you say Stack.


                
> Issue with only using the old config param hbase.hstore.compactionThreshold but not the
corresponding new one
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-5925
>                 URL: https://issues.apache.org/jira/browse/HBASE-5925
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Anoop Sam John
>            Priority: Minor
>
> One observation while going through the code:-
> In MemStoreFlusher constructor
> {code}
> this.blockingStoreFilesNumber =
>       conf.getInt("hbase.hstore.blockingStoreFiles", 7);
>     if (this.blockingStoreFilesNumber == -1) {
>       this.blockingStoreFilesNumber = 1 +
>         conf.getInt("hbase.hstore.compactionThreshold", 3);
>     }
> {code}
> Here as per the code if hbase.hstore.blockingStoreFiles is configured as -1, we are making
this value to be 1+ min files to compact
> But here we read the old config item only!
> Here also we need to read the new config 1st and if not there then the old one.. Is this
a miss?
> Like
> conf.getInt("hbase.hstore.compaction.min",
>          conf.getInt("hbase.hstore.compactionThreshold", 3))

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message