[
https://issues.apache.org/jira/browse/HBASE-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-7843:
------------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
In trunk and 0.95
> enable encapsulating compaction policy/compactor/store file manager
> interaction shennanigans
> --------------------------------------------------------------------------------------------
>
> Key: HBASE-7843
> URL: https://issues.apache.org/jira/browse/HBASE-7843
> Project: HBase
> Issue Type: Improvement
> Components: Compaction
> Affects Versions: 0.96.0
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Priority: Critical
> Fix For: 0.95.0
>
> Attachments: HBASE-7843-v0.patch, HBASE-7843-v1.patch,
> HBASE-7843-v2.patch
>
>
> To avoid massive casting and/or deciphering of structures traveling between
> SFM, compaction policy, and compactor in non-trivial compaction schemes like
> stripe or level, we need to make interaction between themselves hidden.
> Elsewhere, the changes are being made to coprocessor for compactions that
> will make CompactionRequest a limited-visibility class for users, with
> coprocessors being able to subclass and return it. -This seems like a viable
> solution for the problem at hand too. Policy will (optionally) subclass
> compaction request and return it. Instead of calling something.compact(req),
> req.compact() will be called (with "something" already stored inside req as
> of now), after which, magic will happen.-
> After merging that code I actually see that subclassing compactionrequest in
> both will break the policy, or require bunch of ugly code in coprocessors (a
> subclass for every policy, and telling them apart.
--
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
