[
https://issues.apache.org/jira/browse/HBASE-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587716#action_12587716
]
stack commented on HBASE-532:
-----------------------------
I was going to reinstate history array and then have the memcache scanner open
iterators on all history array members. Flusher would clear the tail of the
array on occasion. Scanners would still have hold references to history array
elements so it could keep going.
Bryan D suggested that we just not open iterators at all. He suggested that we
just refactor Memcache Scanners so they use the get and getFull Memcache
primitives. We'd add a getNext kind of thing that would do like
MapFile.getClosest only it would only return the next, not the asked-for row OR
the next closest but the next closest only.
Reviewing, it looks like this approach would simplify things, use less memory
but be slower -- but because the slowness is all up in memory, it won't show in
general scan numbers. I'm having a go at this latter suggestion. Patch soon.
> Odd interaction between HRegion.get, HRegion.deleteAll and compactions
> ----------------------------------------------------------------------
>
> Key: HBASE-532
> URL: https://issues.apache.org/jira/browse/HBASE-532
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.2.0, 0.1.1
> Reporter: Jim Kellerman
> Assignee: stack
> Fix For: 0.2.0, 0.1.2
>
>
> If you apply the patch for HBASE-483 to the 0.1 branch and comment out lines
> 309 and 315 of MetaUtils.java (which force compactions of the root and meta
> regions respectively), TestMergeTool fails. Why forcing compactions makes the
> test succeed is a mystery to me.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
