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

Anoop Sam John commented on HBASE-12295:
----------------------------------------

In CP case also, then we have expectation from user to explicitely call 
close().  We are copying cell considering the fact that it might get stored and 
used later (by CP). Those kind of use cases (HIndex for eg:) might not be 
always the case.  So we can say if the CP has such a case then they have to be 
aware of this SharedMemoryCell and do copy on their own? Just throwing thoughts 
coming.

For non java case, any way we will need a copy. Right now using 
HBaseZeroCopyByteString we avoid the copy need to make a PBCell from Cell. But 
all types of ByteString from PB need a byte[] as backing data structure. When 
the cells are backed by DBB, we have to copy here.  So there is not much adv we 
get. I would say in such a scenario copy the cell at one shot in Region level 
is better. 

> Prevent block eviction under us if reads are in progress from the BBs
> ---------------------------------------------------------------------
>
>                 Key: HBASE-12295
>                 URL: https://issues.apache.org/jira/browse/HBASE-12295
>             Project: HBase
>          Issue Type: Sub-task
>          Components: regionserver, Scanners
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 2.0.0
>
>         Attachments: HBASE-12295.pdf, HBASE-12295_trunk.patch
>
>
> While we try to serve the reads from the BBs directly from the block cache, 
> we need to ensure that the blocks does not get evicted under us while 
> reading.  This JIRA is to discuss and implement a strategy for the same.



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

Reply via email to