hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duo Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18169) Coprocessor fix and cleanup before 2.0.0 release
Date Wed, 23 Aug 2017 08:43:00 GMT

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

Duo Zhang commented on HBASE-18169:

When revisiting HBASE-16320 I found that the {{Store}} and {{StoreFile}} related CPs are totally
messed up...

We have a {{preCompactScannerOpen}} and a {{preCompact}}, which are all aimed to replace the
source scanner which is used for compaction. But in fact, there is no way to create a {{StoreScanner}}
without touching the IA.Private classes. So the only possible way seems to be wrapping the
{{InternalScanner}} and doing filtering in that class. I think it is acceptable for most cases?
What do you guys think? Do we still need to give user the ability to create a {{StoreScanner}}?
Or just cleanup our CP interfaces and tell user that you should not try to create a {{StoreScanner}}
any more, just wrap the given {{InternalScanner}}?

We need to hurry up. This will be a big project, lots of API changes.


> Coprocessor fix and cleanup before 2.0.0 release
> ------------------------------------------------
>                 Key: HBASE-18169
>                 URL: https://issues.apache.org/jira/browse/HBASE-18169
>             Project: HBase
>          Issue Type: Improvement
>          Components: Coprocessors
>    Affects Versions: 2.0.0-alpha-1
>            Reporter: Duo Zhang
>            Priority: Blocker
>             Fix For: 2.0.0-alpha-3
> As discussed in HBASE-18038. In RegionServerServices, Region and StoreFile interfaces
we expose too many unnecessary methods. We need to find a way to not expose these methods
to CP.

This message was sent by Atlassian JIRA

View raw message