[
https://issues.apache.org/jira/browse/HBASE-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609415#comment-13609415
]
Sergey Shelukhin commented on HBASE-8024:
-----------------------------------------
bq. if (DefaultStoreFlusher.flush_retries_number == 0)
Configuration can be different for each store, statics may not be good.
storeFile field on flusher is set and used only in commit(), is the field
needed?
Overall, I wonder if there's better way to abstract flusher interface.
First, it would be nice if there'd be single flusher per store, like with
compactor or policy. Only about half of the things in flusher now are not the
same for every flush against a store, they could be passed in as FlushRequest
or whatever.
Then, what's the story for code reuse for different flushers. What parts will
they replace and reuse, and how? Do you have example flusher?
Then (related to the first), for example, commit() does a sequence of Store
operations and only contributes one path to it (and snapshot, which it got from
store before). Maybe string/snapshot should be passed to store instead, if this
behavior is common between flushers. Similar bits in internalFlushCache to a
lesser degree.
> Make Store flush algorithm pluggable
> ------------------------------------
>
> Key: HBASE-8024
> URL: https://issues.apache.org/jira/browse/HBASE-8024
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Affects Versions: 0.95.0, 0.96.0, 0.94.5
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Attachments: HBASE-8024-trunk.patch, HBASE-8024.v2.patch
>
>
> The idea is to make "StoreFlusher" an interface instead of an implementation
> class, and have the original StoreFlusher as the default store flush impl.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
