[
https://issues.apache.org/jira/browse/HBASE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018970#comment-15018970
]
stack commented on HBASE-13082:
-------------------------------
bq. Will update the comment and say that 'these files are not included in
reads'? The name 'compactedfiles' is still better?
Yeah. When I see the change in context, compactedfiles is good name. You need
to do a bunch of explaining of what there are though... and here is a good
place to do it ("List of the files that were replaced by new ones on
compaction; will be deleted once there are no longer any references by ongoing
scanners to these files..."
bq. ...Used only while closing the store files.
One threaded because close is done with a lock held, right.... that's good.
Might just say on the method that caller needs to ensure
single-thread-at-a-time access.
bq. I think you were referring to some old patch. The patch that was latest was
_14.
Argh!!!! Was looking at v9. My fault.
bq. Generic in the sense?
Its ok. You removed one of the two methods. That is good enough.
bq. We cannot have this in StorefileInfo because we only cache the Storefile
(in the StorefileManager) and not the StorefileInfo. StoreFileInfos are created
every time from the hfile path.
Hmmm... this don't seem right. Ok for now but we should address this. If SFI,
should be not confined in its use... we keep meta data sometimes in SFI and
then other times we modify SF.
bq. Ya we can have ACTIVE and COMPACTED_AWAY.?
Do we even need two states? Could we not just stamp a StoreFile STALE or
COMPACTED_AWAY? A SF has this attribute or it does not. Do we even have to
stamp the SF with this property at all? We are keeping a running list up in
SFManager. Why we need this?
Let me go back to v14. Will be back w/ more comments.
> Coarsen StoreScanner locks to RegionScanner
> -------------------------------------------
>
> Key: HBASE-13082
> URL: https://issues.apache.org/jira/browse/HBASE-13082
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: ramkrishna.s.vasudevan
> Attachments: 13082-test.txt, 13082-v2.txt, 13082-v3.txt,
> 13082-v4.txt, 13082.txt, 13082.txt, HBASE-13082.pdf, HBASE-13082_1.pdf,
> HBASE-13082_12.patch, HBASE-13082_13.patch, HBASE-13082_14.patch,
> HBASE-13082_1_WIP.patch, HBASE-13082_2.pdf, HBASE-13082_2_WIP.patch,
> HBASE-13082_3.patch, HBASE-13082_4.patch, HBASE-13082_9.patch,
> HBASE-13082_9.patch, HBASE-13082_withoutpatch.jpg, HBASE-13082_withpatch.jpg,
> LockVsSynchronized.java, gc.png, gc.png, gc.png, hits.png, next.png, next.png
>
>
> Continuing where HBASE-10015 left of.
> We can avoid locking (and memory fencing) inside StoreScanner by deferring to
> the lock already held by the RegionScanner.
> In tests this shows quite a scan improvement and reduced CPU (the fences make
> the cores wait for memory fetches).
> There are some drawbacks too:
> * All calls to RegionScanner need to be remain synchronized
> * Implementors of coprocessors need to be diligent in following the locking
> contract. For example Phoenix does not lock RegionScanner.nextRaw() and
> required in the documentation (not picking on Phoenix, this one is my fault
> as I told them it's OK)
> * possible starving of flushes and compaction with heavy read load.
> RegionScanner operations would keep getting the locks and the
> flushes/compactions would not be able finalize the set of files.
> I'll have a patch soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
