Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9AB0810686 for ; Fri, 21 Mar 2014 00:58:55 +0000 (UTC) Received: (qmail 62327 invoked by uid 500); 21 Mar 2014 00:58:48 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 62296 invoked by uid 500); 21 Mar 2014 00:58:48 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 62279 invoked by uid 99); 21 Mar 2014 00:58:47 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Mar 2014 00:58:47 +0000 Date: Fri, 21 Mar 2014 00:58:47 +0000 (UTC) From: "Hudson (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-10270) Remove DataBlockEncoding from BlockCacheKey MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-10270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942610#comment-13942610 ] Hudson commented on HBASE-10270: -------------------------------- FAILURE: Integrated in HBase-TRUNK #5028 (See [https://builds.apache.org/job/HBase-TRUNK/5028/]) HBASE-10752 Port HBASE-10270 'Remove DataBlockEncoding from BlockCacheKey' to trunk (tedyu: rev 1579742) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/BlockCache.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/BlockCacheKey.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlockIndex.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileDataBlockEncoder.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileDataBlockEncoderImpl.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileWriterV2.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/NoOpDataBlockEncoder.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/CompoundBloomFilter.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHeapSize.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestCacheOnWrite.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockIndex.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestLruBlockCache.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCacheOnWriteInSchema.java > Remove DataBlockEncoding from BlockCacheKey > ------------------------------------------- > > Key: HBASE-10270 > URL: https://issues.apache.org/jira/browse/HBASE-10270 > Project: HBase > Issue Type: Improvement > Components: regionserver > Affects Versions: 0.89-fb > Reporter: Arjen Roodselaar > Assignee: Arjen Roodselaar > Priority: Minor > Fix For: 0.89-fb > > Attachments: datablockencoding_blockcachekey.patch > > > When a block is added to the BlockCache its DataBlockEncoding is stored on the BlockCacheKey. This block encoding is used in the calculation of the hashCode and as such matters when cache lookups are done. Because the keys differ for encoded and unencoded (data) blocks, there is a potential for caching them twice or missing the cache. This happens for example when using Scan preloading as AbstractScannerV2.readNextDataBlock() does a read without knowing the block type or the encoding. > This patch removes the block encoding from the key and forces the caller of HFileReaderV2.readBlock() to specify the expected BlockType as well as the expected DataBlockEncoding when these matter. This allows for a decision on either of these at read time instead of cache time, puts responsibility where appropriate, fixes some cache misses when using the scan preloading (which does a read without knowing the type or encoding), allows for the BlockCacheKey to be re-used by the L2 BucketCache and sets us up for a future CompoundScannerV2 which can read both un-encoded and encoded data blocks. > A gotcha here: ScannerV2 and EncodedScannerV2 expect BlockType.DATA and BlockType.ENCODED_DATA respectively and will throw when given a block of the wrong type. Adding the DataBlockEncoding on the cache key caused a cache miss if the block was cached with the wrong encoding, implicitly defining the BlockType and thus keeping this from happening. It is now the scanner's responsibility to specify both the expected type and encoding (which is more appropriate). -- This message was sent by Atlassian JIRA (v6.2#6252)