[
https://issues.apache.org/jira/browse/HBASE-18905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16186707#comment-16186707
]
Andrew Purtell commented on HBASE-18905:
----------------------------------------
Copying my comment from HBASE-18906:
I think we should consider providing APIs for the following:
Request flush async
Request compaction async
Poll for the completion of a single flush request
Poll for the completion of a single compaction request
Wait for all pending flushes to complete on the region
Wait for all pending compactions to finish on the region
It's a good idea to get away from providing access to low level implementation
details. However I think it would be good to allow coprocessors to wrap the
behaviors. One example: guarantee persistence in HFiles: write some data,
trigger a flush (API needed), wait for flushes to complete (API needed), then
do more stuff. Another example: secure delete: lay some delete markers, trigger
flushing and compactions (APIs needed), wait for the activity to complete (API
needed), then do more stuff.
> Allow CPs to request flush/compaction on Region
> -----------------------------------------------
>
> Key: HBASE-18905
> URL: https://issues.apache.org/jira/browse/HBASE-18905
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> Follow up for HBASE-18183
> As per that Jira, we keep only requestCompaction API in Region. We did not
> have any such for flush in Region. Only API which was there is a flush which
> will block the callee unless flush is done. This issue has to tacke
> 1. Decide whether we need a requestFlush in Region and if so add
> 2. Whether the requestCompaction (And requestFlush too) should return a
> Future? Right now the former do not return any but allow to pass a
> CompactionLifeCycleTracker which will get notified on start and end of
> compaction.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
