[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14564180#comment-14564180
]
stack commented on HBASE-12295:
-------------------------------
bq. You mean add some different type of keys for the L1 or L2 case? Can check
this.
Yeah. Type or you check L2 and there is no corresponding count associated. It
is just odd passing in the actual object when done with it. You going to mark
the object as from L2 or something?
bq. When we were writing every cell to the socket directly things were really
slow.
Ok. Would be good to see what is going on at that time. Can do later.
bq. ...see if we can make the REsult carry this cellblock. Will check on this
once again.
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.
bq. Yes but only if the scanner returned from the CP hook is not implementing
the new interface....
New Interface? I missed that. Let me reread the doc.
bq. Ya, I tried out something yesterday. Seems to work.
Ok. Good. Better than introducing a new close-like method. Complicated.
bq. Just the block block in the Bucket cache itself would know this and do it.
Could we not have the special casing here (I don't know what I'm talking about
... this is a totally removed, high-level comment... ignore if nonsense)
Sounds good on testing.
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?
What if we had an encoder that could concatenate CellBlocks? Would that help?
Cells come up out of HRegion in Results, right? Its 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. Its like you want to have a 'finally' on Result
but you want to call it yourself rather than have the GC do it.
For Scan, I think you need to look at the context object that was recently
added. It determines when it is time to go back to the client. Again it is
returning a Result. When the Result has been copied to the CellBlock, call its
'finally'?
For scan you say, "...we return back all the blocks used in the read except the
current block (the latest block that was read). The latest block cannot be
returned back because it could be used for the scan’s next ‘next()’ call. "
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.
For CPs, if Result had a 'finally' or 'release' or 'close' on it, they could
let it go when done with it rather than have us do copy? Or, could we have a
Result that explicity has all Cells copied into it and another which has
reference to backing blocks? We would default passing CPs Results that have
had Cells copied into them with all kinds of warning that this is horrid and
they need to switch to do reference Results?
In non-java cases, is there a barrier like there is in rpc for CellBlocks... so
we could do similar for them? Could do the copy for first cut.
I think I understand the compaction case. You are setting a flag so that when
the refcounts go to zero, instead of leaving the block in the bucketcache, you
force it out. Is that it? If so, makes sense.
Thanks lads.
> 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)
