[
https://issues.apache.org/jira/browse/HBASE-10569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934194#comment-13934194
]
stack commented on HBASE-10569:
-------------------------------
bq. # Due to 2, HMaster#getMetrics is renamed to getMasterMetrics to avoid
naming conflict with HRegionServer#getMetrics. The same has been done to
HMaster#getCoprocessors, #getCoprocessorHost.
Make it symmetrical? s/getMetrics/getRegionServerMetrics/
bq. Added HRegionServer#getRpcServices and HMaster#getMasterRpcServices to
expose the RPC functionalities.
Why expose these? Were they exposed before? When I ask the master for its rpc
engine, will it be the same as the regionservers? (It sounds like they will be
the same going by #6). If so, should the method be getRpcServices whether on
Master or on HRegionServrer (add it to the Server Interface?).
Do you mean RpcServiceInterface or RpcServerInterface? If the latter, change
it all you want. What is there currently is a bit of a mess.
bq. Master recovery in case of ZK connection loss is removed since it doesn’t
recover listeners added in HRegionServer.
This was a bad idea in the first place? Or rather, it improved our 'usability'
when a single Master only in that Master would 'come back to life'....but if
backup Masters, it was racing the backup Master? (IIRC).
Let me look at the patch.
This is great Jimmy.
> Co-locate meta and master
> -------------------------
>
> Key: HBASE-10569
> URL: https://issues.apache.org/jira/browse/HBASE-10569
> Project: HBase
> Issue Type: Improvement
> Components: master, Region Assignment
> Reporter: Jimmy Xiang
> Assignee: Jimmy Xiang
> Attachments: hbase-10569_v1.patch
>
>
> I was thinking simplifying/improving the region assignments. The first step
> is to co-locate the meta and the master as many people agreed on HBASE-5487.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
