hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-15982) Interface ReplicationEndpoint extends Guava's Service
Date Thu, 24 Aug 2017 05:48:00 GMT

     [ https://issues.apache.org/jira/browse/HBASE-15982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

stack updated HBASE-15982:
--------------------------
    Release Note: 
    Breaking change to our ReplicationEndpoint and BaseReplicationEndpoint.

    ReplicationEndpoint implemented Guava 0.12 Service. An abstract
    subclass, BaseReplicationEndpoint, provided default implementations
    and facility, among other things, by extending Guava's
    AbstractService class.

    Both of these HBase classes were marked LimitedPrivate for
    REPLICATION so these classes were semi-public and made it so
    Guava 0.12 was part of our API.

    Having Guava in our API was a mistake. It anchors us and the
    implementation of the Interface to Guava 0.12. This is untenable
    given Guava changes and that the Service Interface in particular
    has had extensive revamp and improvement done. We can't hold to
    the Guava Interface. It changed. We can't stay on Guava 0.12;
    implementors and others on our CLASSPATH won't abide being stuck
    on an old Guava.

    So we make breaking changes. The unhitching of our Interface
    from Guava could only be done in a breaking manner. It undoes the
    LimitedPrivate on BaseReplicationEndpoint while keeping it for the RE
    Interface. It means consumers will have to copy/paste the
    AbstractService-based BRE into their own codebase also supplying their
    own Guava; HBase no longer 'supplies' this (our Guava usage has
    been internalized, relocated).

    This patch then adds into RE the basic methods RE needs of the old
    Guava Service rather than return a Service to start/stop only to go
    back to the RE instance to do actual work. A few method names had to
    be changed so could make implementations with Guava Service internally
    and not have RE method names and types clash). Semantics remained the
    same otherwise. For example startAsync and stopAsync in Guava are start
    and stop in RE.

> Interface ReplicationEndpoint extends Guava's Service
> -----------------------------------------------------
>
>                 Key: HBASE-15982
>                 URL: https://issues.apache.org/jira/browse/HBASE-15982
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Andrew Purtell
>            Assignee: stack
>            Priority: Blocker
>             Fix For: 2.0.0-alpha-3
>
>         Attachments: HBASE-15982.master.001.patch, HBASE-15982.master.002.patch, HBASE-15982.master.003.patch
>
>
> We have Guava's Service leaking into the LimitedPrivate interface ReplicationEndpoint:
> {code}
> public interface ReplicationEndpoint extends Service, ReplicationPeerConfigListener
> {code}
> This required a private patch when I updated Guava for our internal deployments. This
is going to be a problem for us for long term maintenance and implenters of pluggable replication
endpoints. LP is only less than public by a degree. We shouldn't leak types from third part
code into either Public or LP APIs in my opinion. Let's fix.



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

Mime
View raw message