hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matteo Bertozzi (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11497) Expose RpcScheduling implementations as Public Interfaces
Date Fri, 11 Jul 2014 06:34:06 GMT

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

Matteo Bertozzi commented on HBASE-11497:

Does the InterfaceAudience means that you not only have to preserve the public methods but
also the "open" methods/members of the class?

e.g. With the latest changes SimpleRPCScheduler has not changed the public interface (all
the methods aside 1 private are still there), but the 3 queues that were open at the package
level were removed.
 -  final BlockingQueue<CallRunner> callQueue;
 -  final BlockingQueue<CallRunner> priorityCallQueue;
 -  final BlockingQueue<CallRunner> replicationQueue;

> Expose RpcScheduling implementations as Public Interfaces
> ---------------------------------------------------------
>                 Key: HBASE-11497
>                 URL: https://issues.apache.org/jira/browse/HBASE-11497
>             Project: HBase
>          Issue Type: Improvement
>          Components: io, regionserver, Usability
>    Affects Versions: 0.99.0, 0.98.4
>            Reporter: Jesse Yates
>            Assignee: Jesse Yates
>             Fix For: 0.99.0, 0.98.4, 2.0.0
>         Attachments: hbase-11497-0.98-v0.patch
> In PHOENIX-938 we are attempting to resolve cross-RS deadlocks in indexing by adding
custom RPC handlers (so regular puts/reads don't interfere with index updates). However, we've
run into a couple of snags where the interfaces change, making it a bit more difficult to
support interoperability between minor versions as the underlying RPC handling changed (for
the better, but still different :).
> This would just mark those interfaces Public, Evolving, so we still have some flexibility,
but don't break existing usage.
> Note, this kind of thing will come up for any client who is doing custom RPC handling
- beyond the recently added flexibility - but wants to stay in line with the current HBase
implementation (rather than building their own RPC handling mechanisms).

This message was sent by Atlassian JIRA

View raw message