[
https://issues.apache.org/jira/browse/HBASE-12295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563680#comment-14563680
]
stack commented on HBASE-12295:
-------------------------------
bq. May be we can only pass the type of the block there? That should be
possible. Not a big deal.
You can't figure whether L1 or L2 looking at the key?
bq. When we tried to directly write the cells to the socket as part of the POC
things were directly slow.
We'll have to dig in on why. You'd think w/ less intermediaries that it would
be faster.
bq. Making Result carry it is one option, I think you mean the PB result right?
Ain't sure (smile). I was thinking in both cases. Result would give you a
CellScanner... client or server side.
Result cuts at a different dimension from CellBlock though, right? You get a
Result per Get and per Scan response (could be full row or partial). CellBlock
is an RPC primitive. Thought was that CellBlock could go other places in HBase
too to save space (encoding/compression): e.g. in hfileblock or backing a
Result.
bq. The approach here was to be simple use the existing Payload. When you say
Result - will that not be the current way as how we do for non-java clients?
Understood.
But pulling the rpc controller back into HRegion is a little perverse. HRegion
should not have any rpc pollution. Also, we already pervert rpc controller to
carry the payload across the server/rpc barrier, an unnatural usage. Then,
controller itself is not actually doing any 'controlling' of the rpc -- it is
just a place holder in rpc that protobuf actually recommends we avoid (i.e.
generate own rpc interface rather than use the one protoc generates).
bq. Yes, this will be a zero copy.
But we are copying Cells into CellBlock in memory and then we put the CellBlock
on the wire? Would be nice if we could write the CellBlock directly on the wire
(maybe this is not possible....). That said, for now at least, the creation of
CellBlock is a good place for triggering decrement of backing block reference.
bq. Scans have states and gets do not have states as gets operate with in
Region.
Scans are Gets. If that is not enough, can we mimic scan context in Get? Would
that help? Then we could have one means rather than two keeping account.
bq. ...and the CP tries to use those Cells as its state.
So, as is, we'll make a copy per registered CP?
bq. finalizeScan(boolean finalizeAll).
You want a delayed close, one that completes only after all outstanding
scanners are done? Can we have scanner close set up one of these?
So the boolean does what for compacted files? It says, don't evict files that
are being read though they have been compacted? (Is this like the finalizeScan
case at all? Where you want to do a delayed close until no more references?)
One other thought is how you folks thinking of testing this stuff?
> 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)
