[
https://issues.apache.org/jira/browse/HBASE-5905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13270818#comment-13270818
]
stack commented on HBASE-5905:
------------------------------
If we were to make an InternalClusterProtocol, we could:
1. Subclass the user-facing open and close messages (thats all that would need
it as I see it).
2. We could do the internal version of open and close as extensions
(https://developers.google.com/protocol-buffers/docs/proto#extensions) naming
the extensions 'Internal' or something or we could do nested extensions naming
the nested extention ForInternalUse?
I'm thinking that since there are only open and close effected, and since its
only the one field in open and only two in close region, its not enough to
justify doing the above extra work? How about we doc the .proto file 'for
internal use' only and be done with it?
> Protobuf interface for Admin: split between the internal and the
> external/customer interface
> --------------------------------------------------------------------------------------------
>
> Key: HBASE-5905
> URL: https://issues.apache.org/jira/browse/HBASE-5905
> Project: HBase
> Issue Type: Improvement
> Components: client, master, regionserver
> Affects Versions: 0.96.0
> Reporter: nkeywal
>
> After a short discussion with Stack, I create a jira.
> --
> I'am a little bit confused by the protobuf interface for closeRegion.
> We have two types of closeRegion today:
> 1) the external ones; available in client.HBaseAdmin. They take the server
> and the region identifier as a parameter and nothing else.
> 2) The internal ones, called for example by the master. They have more
> parameters (like versionOfClosingNode or transitionInZK).
> When I look at protobuf.ProtobufUtil, I see:
> public static void closeRegion(final AdminProtocol admin,
> final byte[] regionName, final boolean transitionInZK) throws
> IOException {
> CloseRegionRequest closeRegionRequest =
> RequestConverter.buildCloseRegionRequest(regionName, transitionInZK);
> try {
> admin.closeRegion(null, closeRegionRequest);
> } catch (ServiceException se) {
> throw getRemoteException(se);
> }
> }
> In other words, it seems that we merged the two interfaces into a single one.
> Is that the intend?
> I checked, the internal fields in closeRegionRequest are all optional (that's
> good). Still, it means that the end user could use them or at least would
> need to distinguish between the "optional for functional reasons" and the
> "optional - do not use".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
