[
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)
