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 A90C618F2D for ; Wed, 30 Sep 2015 06:57:04 +0000 (UTC) Received: (qmail 10674 invoked by uid 500); 30 Sep 2015 06:57:04 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 10616 invoked by uid 500); 30 Sep 2015 06:57:04 -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 10603 invoked by uid 99); 30 Sep 2015 06:57:04 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Sep 2015 06:57:04 +0000 Date: Wed, 30 Sep 2015 06:57:04 +0000 (UTC) From: "ramkrishna.s.vasudevan (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-14398) Create the fake keys required in the scan path to avoid copy to byte[] 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-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936457#comment-14936457 ] ramkrishna.s.vasudevan commented on HBASE-14398: ------------------------------------------------ Thanks Stack. bq.One thought I had looking at this ByteBufferedCell Interface is how unwieldy the method names are. getTagsPositionInByteBuffer is a bit of a mouth full. Can this be getXXXBufferOffset()? bq.What was the reason that we could not just use the Cell#getTagsOffset method and use its offset as 'index' into the backing BB? This was a long discussion that we had before finalising. The BytebufferedCell, an extension of Cell used in the Server side introduces these new APIs for accessing the offset info on the BBs. Though we can have onheap and offheap backed BB cells, when we see that a Cell is backed by onheap Bb we still create a normal Keyvalue only using the BB.array() and BB.arrayOffset() API. So for now there is only one thing to be taken care of - OffheapBB backed Cells. Here first of all we don't have the arrayOffset information and only have the BB's offset information on from where the Cell would start. Now when we don have specific APIs for BB offsets, then if we try to use getXXXArray and getXXXOffset and getXXXBuffer and getXXXOffset what should be returned? Then in that case calling getXXXArray() on an offheap cell should always be throwing an exception. But we don't want that to happen. Assume if we start throwing exception if getXXXArray() is called on an offheap Cell then we need to change its usage throughout the code. You may remeber the hasArray API in Cell and that was spread through out the code in our initial versions. So inorder to clearly distinguish the offset information, having specific APIs for array offset and BB offset would be needed. Now these changes are confined to CellUtil and CellComparator and there we decide what offset APIs needs to be used based on the cell type. Even now on an offheap Cell if getXXXArray() and getXXXOffset() is used we copy the cell's component and return the offset as 0. This clear difference we will not be able to make if we don't have seperate APIs for offset. Let us know if you have further queries. > Create the fake keys required in the scan path to avoid copy to byte[] > ---------------------------------------------------------------------- > > Key: HBASE-14398 > URL: https://issues.apache.org/jira/browse/HBASE-14398 > Project: HBase > Issue Type: Sub-task > Reporter: ramkrishna.s.vasudevan > Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-14398.patch, HBASE-14398_1.patch > > > Already we have created some fake keys for the ByteBufferedCells so that we can avoid the copy requried to create fake keys. This JIRA aims to fill up all such places so that the Offheap BBs are not copied to onheap byte[]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)