hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2087) The wait on compaction because "Too many store files" holds up all flushing
Date Sun, 03 Jan 2010 22:52:54 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796046#action_12796046

stack commented on HBASE-2087:

@J-D: "...flushing incomplete memstores is highly inefficent.."  ... yeah but if the edit
is old, its probably worth the flush if you take a systems view.  And this issue is about
something else anyway, never holding up flushes.  Should we open a blanket issue in which
we discuss undoing "compensating" changes now hdfs has a working sync; i.e.undo all the weird
stuff we did to try and minimize losing edits when there was no working sync.

> The wait on compaction because "Too many store files" holds up all flushing
> ---------------------------------------------------------------------------
>                 Key: HBASE-2087
>                 URL: https://issues.apache.org/jira/browse/HBASE-2087
>             Project: Hadoop HBase
>          Issue Type: Bug
>            Reporter: stack
> The method MemStoreFlusher#checkStoreFileCount is called from flushRegion.  flushRegion
is called by MemStoreFlusher#run thread.  If the checkStoreFileCount finds too many store
files, it'll stick around waiting on a compaction to happen.  While its hanging, the MemStoreFlusher#run
is held up.  No other region can flush.  Meantime WALs will be rolling and memory will be
accumulating writes.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message