[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564705#comment-14564705
]
ramkrishna.s.vasudevan commented on HBASE-12295:
------------------------------------------------
Was not available for some time during the day today. Anyway Anoop had chimed
in.
bq.Where are the refcounts to be kept? In the block key itself? Or in a Map
keyed by the block key? Or in the HFileScanner? Or in the HFile reader
implementation?
Ref counts purely happens in the L2_CACHE layer alone and the ref count is
associated with the bucket entry. None of the above layers know about it.
The list of blocks to be used is there in the HFileREader (HfileScanner
internally).
The current scan case is quite complex and handling the pseudo close call for
intermedidate cases seems will have more involved changes - let's see.
Scannercontext, I had a look but all cases we have hasMoreValues as true except
for NO_MORE_VALUES. I think we just need this information before confirming if
we can decrement the blocks ref count.
Regarding the result part, your idea is right, but apart from the concerns that
Anoop raised as Result is a client side thing, if Result needs to do the
'finally' may be it should be exposed to some more internals of the scans and
the scanners?
bq.Will you want to return many Results in the one go? I'm am wondering if
Result operates on a different dimension to what you need.
I think you make that point here.
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
Could be done but as Anoop said it has an overhead for then next next() call
and logically holding that block is fine - as we really know it is a hot block.
If the current next() call would really know that there are no more results to
be fetched it would have already ensured that the current block would not be
reused. So I feel that maintaining the last block is needed and logically
right too.
> 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)
