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 LimitedPrivate interfaces
Date Mon, 14 Jul 2014 08:39:05 GMT

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

Matteo Bertozzi commented on HBASE-11497:
-----------------------------------------

question... How can I add a method to RpcScheduler without breaking phoenix?
If I add a method to the interface phoenix will have to implement that method, which means
different code for different hbase releases.
if I change the class to abstract to avoid every existing class to be forced to implement
the new method, the code will not compile since instead of implements you have to use extends..

any idea?

> Expose RpcScheduling implementations as LimitedPrivate 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.patch, HBASE-11497.patch, 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
(v6.2#6252)

Mime
View raw message