[
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)