[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563069#comment-14563069
]
stack commented on HBASE-12295:
-------------------------------
Thank you for the nice writeup. It helps. It looks great. It is easier
discussing around a doc like this than looking at a ream of code (smile).
returnBlock(BlockCacheKey cacheKey, HFileBlock block)
Do we need to return the block too in the above? Won't the key be enough?
"As mentioned earlier the cellblock creation would ensure that the cells are
copied to an output
stream and thus we are sure that the reference of these cells to the shared
memory area is
removed."
I would say that the creation of the CellBlock in memory is something we would
like to get away from some day. We would like to just put the bytes on the wire
directly. Or, consider that we will want to stream out Cells as they come up
out of the server when we implement a streaming Interface on the server. Just
something to keep in mind.
" To achieve this, we are converting the cells in the result to a Cellblock
buffer (in
Region level itself) and pass it to RpcServer via the Payload of the controller
as opposed to how
it happens currently (currently the cell block is created in RPC layer)."
Hmm... pulling the CellBlock into the Region from the ipc layer? I have thought
that Result should carry CellBlocks.... This would be an extra copy, right? If
we wanted to get to zero copy, would it be possible if we went this route?
"We have added an overridden API in HRegion which takes RpcController as
parameter. "
HRegion.get(get, RpcController)
Nah. You can't pull an oddball RPC datastructure back into HRegion. Could it be
done in the Result itself?
Ditto here: HRegion.getScanner(scan, RPCController).
Have you seen Jonathan Lawlor's ScanContext? He has added a bunch of accounting
on where scan is at... state, and has scans doing heartbeating, and early
returns. Can you make use of this work of his?
Tell us more about the marking of Cells from L2 with a new Interface and why CP
need special treatment, need Cells copied when read from CP. We have to do this?
{quote}Only the required results are copied.{quote}
This is a good point to make. May be raise it in the design doc higher... A
'benefits' section.
{quote} finalizeScan(boolean finalizeAll). {quote}
Why we need this? Why not close (sorry if I'm being thick).
I don't follow this sentence: "In such a case we don’t evict the block if the
ref count > 0, instead we mark those
blocks with a Boolean."
> 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)
