[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564194#comment-14564194
]
Anoop Sam John commented on HBASE-12295:
----------------------------------------
bq.Why not just let the current block go? Deprecate its count? It might get
evicted before the scanner comes back with a next, but that'd be ok? The block
must have been cold? Otherwise, it'll just be in cache next time we come in.
Not really we can. Because if we do so, every time next() comes, we have to ask
the cache to give me the cached block. This is not happening now. So we would
like to avoid this overhead.
bq.ts like the Result should have a reference to the backing block and when RPC
is 'done' with a Result, it calls 'close' or 'done' or 'finally' on the Result
and that means the Result and its backing block can be let go
But there can be N results which have the ref to same block(s) no? So it is bit
complicated then. Also we did not want the concept of blocks or cache to come
to upper layers after the HFileScanner layer.
The ref counting is happening within the BC impl. Not even all BCs need this.
Say the File based BC, we better copy buckets to a single buffer. This also we
try to handle..
> 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)
