[
https://issues.apache.org/jira/browse/HBASE-19134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16282455#comment-16282455
]
stack commented on HBASE-19134:
-------------------------------
.002 should be ready to go. Creates a new WALKey Interface and a WALKeyImpl.
The WALKey Interface is surfaced to Coprocessors and throughout most of the
code base. WALKeyImpl is used internally by WAL and by Replication which need
access to WALKey setters. Methods that were deprecated in WALObserver because
they were exposing Private audience Classes have been un-deprecated now we have
WALKey. Moved over to use SequenceId#getSequenceId throughout. Changed
SequenceId#getSequenceId removing the IOE.
> 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
>
> Attachments: HBASE-19134.master.001.patch,
> HBASE-19134.master.002.patch
>
>
> 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)
