[
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.
