[
https://issues.apache.org/jira/browse/HBASE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058160#comment-14058160
]
Andrew Purtell commented on HBASE-11497:
----------------------------------------
bq. It seems like a LimitedPrivate with either Coprocessors or similar
audience would be a better target.
{code}
@InterfaceAudience.LimitedPrivate({"Coprocessor","Phoenix"})
{code}
could work as long as the RM checks with the designated users. For 0.98 I can
definitely do that. What do you think [~jesse_yates]?
> 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
>
> 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)
