[hbase] branch master updated: HBASE-22873 Typo in block caching docs

[re...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

reidchan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/hbase.git


The following commit(s) were added to refs/heads/master by this push:
     new 7903f55  HBASE-22873 Typo in block caching docs
7903f55 is described below

commit 7903f55c18d561d7451e91b8a014936a3116f142
Author: Shuai Lin <li...@gmail.com>
AuthorDate: Sat Aug 17 19:10:46 2019 +0800

    HBASE-22873 Typo in block caching docs
    
    Signed-off-by: Reid Chan <re...@apache.org>
---
 src/main/asciidoc/_chapters/architecture.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/main/asciidoc/_chapters/architecture.adoc b/src/main/asciidoc/_chapters/architecture.adoc
index a2fe2f1..848b8fd 100644
--- a/src/main/asciidoc/_chapters/architecture.adoc
+++ b/src/main/asciidoc/_chapters/architecture.adoc
@@ -837,7 +837,7 @@ Here are two use cases:
   Setting block caching on such a table is a waste of memory and CPU cycles, more so that it will generate more garbage to pick up by the JVM.
   For more information on monitoring GC, see <<trouble.log.gc>>.
 * Mapping a table: In a typical MapReduce job that takes a table in input, every row will be read only once so there's no need to put them into the block cache.
-  The Scan object has the option of turning this off via the setCaching method (set it to false). You can still keep block caching turned on on this table if you need fast random read access.
+  The Scan object has the option of turning this off via the setCacheBlocks method (set it to false). You can still keep block caching turned on on this table if you need fast random read access.
   An example would be counting the number of rows in a table that serves live traffic, caching every block of that table would create massive churn and would surely evict data that's currently in use.
 
 [[data.blocks.in.fscache]]