[
https://issues.apache.org/jira/browse/HBASE-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571574#action_12571574
]
stack commented on HBASE-69:
----------------------------
I'd suggest making a new patch that has in it the improvements that are
contained in this patch and lets commit that (probably in a new issue). Here's
some comments:
+ +1 on FSUtils changes.
+ On migrations, would suggest that you emit logging of what step you are
currently in: e.g. "moving to version 2". Will help should a step fail.
+ This is not a change made by you in Migrate but I wonder if the making fully
qualified works w/ our new hbase.rootdir format where you need to specify the
filesystem to use:
{code}
- Path rootdir =
- fs.makeQualified(new Path(this.conf.get(HConstants.HBASE_DIR)));
+ rootdir = fs.makeQualified(new
Path(this.conf.get(HConstants.HBASE_DIR)));
{code}
+ +1 on new names of methods in Migrate.java
+ +1 on IdentityTableReduce.java changes
+ What about the HSK changes? Should we add them? They get rid of
TextSequence. Do you think this change for the better?
+ Whats going on here?
{code}
- final AtomicInteger activeScanners = new AtomicInteger(0);
+ volatile AtomicInteger activeScanners = new AtomicInteger(0);
{code}
Why make reference to 'activeScanners' volatile rather than final? Once
created as part of class creation, its not going to change? Volatile doesn't
effect the content of the AtomicInteger, does it?
+ +1 on change to TestMigrate.java. Fixes currently broken migration scripts
(They are failing on hudson).
Rest of the patch seems like all or nothing.
> [hbase] Make cache flush triggering less simplistic
> ---------------------------------------------------
>
> Key: HBASE-69
> URL: https://issues.apache.org/jira/browse/HBASE-69
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: stack
> Assignee: Jim Kellerman
> Fix For: 0.2.0
>
> Attachments: patch.txt, patch.txt, patch.txt, patch.txt, patch.txt,
> patch.txt, patch.txt, patch.txt, patch.txt, patch.txt, patch.txt, patch.txt,
> patch.txt, patch.txt
>
>
> When flusher runs -- its triggered when the sum of all Stores in a Region > a
> configurable max size -- we flush all Stores though a Store memcache might
> have but a few bytes.
> I would think Stores should only dump their memcache disk if they have some
> substance.
> The problem becomes more acute, the more families you have in a Region.
> Possible behaviors would be to dump the biggest Store only, or only those
> Stores > 50% of max memcache size. Behavior would vary dependent on the
> prompt that provoked the flush. Would also log why the flush is running:
> optional or > max size.
> This issue comes out of HADOOP-2621.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
