You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2014/05/17 23:27:14 UTC

[jira] [Updated] (HBASE-11007) BLOCKCACHE in schema descriptor seems not aptly named

     [ https://issues.apache.org/jira/browse/HBASE-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-11007:
--------------------------

    Attachment: 11007.txt

Changed javadoc for BLOCKCACHE and for its methods to explain that a better name would have been CACHE_DATA_ON_READ explaining that this attribute enables DATA block caching, yes/no.

The TestForceCacheImportantBlocks in trunk was testing nothing (since removal of SchemaMetrics).  Cache stats are opaque on whether DATA or META (INDEX/BLOOM).  Let me fix that elsewhere.  Meantime made TestForceCacheImportantBlocks do a very basic verification that when BLOCKCACHE is on/off, that the miss count reflects at least a difference.

> BLOCKCACHE in schema descriptor seems not aptly named
> -----------------------------------------------------
>
>                 Key: HBASE-11007
>                 URL: https://issues.apache.org/jira/browse/HBASE-11007
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.94.18
>            Reporter: Varun Sharma
>            Assignee: Varun Sharma
>            Priority: Minor
>         Attachments: 11007.txt
>
>
> Hi,
> It seems that setting BLOCKCACHE key to false will disable the Data blocks from being cached but will continue to cache bloom and index blocks. This same property seems to be called cacheDataOnRead inside CacheConfig.
> Should this be called CACHE_DATA_ON_READ instead of BLOCKCACHE similar to the other CACHE_DATA_ON_WRITE/CACHE_INDEX_ON_WRITE. We got quite confused and ended up adding our own property CACHE_DATA_ON_READ - we also added some unit tests for the same.
> What do folks think about this ?
> Thanks
> Varun



--
This message was sent by Atlassian JIRA
(v6.2#6252)