Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 17 Oct 2016 11:17:58 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13012792.1476695585000.2963.1476703078492@Atlassian.JIRA>
In-Reply-To: <JIRA.13012792.1476695585000@Atlassian.JIRA>
References: <JIRA.13012792.1476695585000@Atlassian.JIRA> <JIRA.13012792.1476695585576@arcas>
Subject: [jira] [Commented] (HBASE-16859) Use Bytebuffer pool for non java
 clients specifically for scans/gets
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 17 Oct 2016 11:18:00 -0000


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

ramkrishna.s.vasudevan commented on HBASE-16859:
------------------------------------------------

bq.We need to impl a ByteOutput which can work with N buffers and that too from pool.
What I thought was we could create a COS that can work on List of Bytebuffers that we get from the pool. If this is not a list then we can create ByteBuff (MBB) and pass that MBB to the COS and write the data. 
Once the data is written into those MBB, convert it to Bufferchain and rest is going to be how it works currently.
May be you are saying we can impl a ByteOutput that directly works on N buffers? That is also fine.

> Use Bytebuffer pool for non java clients specifically for scans/gets
> --------------------------------------------------------------------
>
>                 Key: HBASE-16859
>                 URL: https://issues.apache.org/jira/browse/HBASE-16859
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 2.0.0
>
>
> In case of non java clients we still write the results and header into a on demand  byte[]. This can be changed to use the BBPool (onheap or offheap buffer?).
> But the basic problem is to identify if the response is for scans/gets. 
> - One easy way to do it is use the MethodDescriptor per Call and use the   name of the MethodDescriptor to identify it is a scan/get. But this will pollute RpcServer by checking for scan/get type response.
> - Other way is always set the result to cellScanner but we know that isClientCellBlockSupported is going to false for non PB clients. So ignore the cellscanner and go ahead with the results in PB. But this is not clean
> - third one is that we already have a RpccallContext being passed to the RS. In case of scan/gets/multiGets we already set a Rpccallback for shipped call. So here on response we can check if the callback is not null and check for isclientBlockSupported. In this case we can get the BB from the pool and write the result and header to that BB. May be this looks clean?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)