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)