You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2017/10/31 13:01:00 UTC

[jira] [Created] (HBASE-19134) Make WALKey an Interface; expose Read-Only version to CPs

stack created HBASE-19134:
-----------------------------

             Summary: Make WALKey an Interface; expose Read-Only version to CPs
                 Key: HBASE-19134
                 URL: https://issues.apache.org/jira/browse/HBASE-19134
             Project: HBase
          Issue Type: Bug
          Components: Coprocessors, wal
            Reporter: stack
            Assignee: stack
             Fix For: 2.0.0-beta-1


WALKey has been made IA.Private in hbase2. Even so, given we don't have an alternative to expose at this time, it is exposed to coprocessors still at a few (now deprecated) locations.

In review of HBASE-18770, [~chia7712] makes reasonable suggestion that what we expose to CPs be a read-only WALKey. He gets pushback on doing this for hbase2 (Do we even want to expose WALKey to CPs, is WALKey right going forward, etc.). Chia-Ping comes back w/ the below (copied from HBASE-18770):

What we want to fix for WALKey are shown below.

 * expose some methods to CP user safety
 * refactor/redo

As I see it, adding an interface exposed to CP user for WALKey is a right choice because it can bring some benefit.

 * We can expose part of WALKey's methods to CP users - a read-only interface or an interface with some modifiable setting. 
 * The related CP hooks won't be deprecated 
 * Doing the refactor for WALKey doesn't essentially impact the CP hook after 2.0 release. 

Although, it will be better to redo WALKey before 2.0 release. In short, I think it warrants such an interface.

(We both agree this would be a load of work given WALKey is written to HFiles. Warrants a look though).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)