[
https://issues.apache.org/jira/browse/HBASE-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019187#comment-13019187
]
stack commented on HBASE-3775:
------------------------------
1502 marks HServerAddress as deprecated and replaces most instances, all but
those that bubble up to the API with a ServerName class. ServerName is just a
host for a String formatted as <HOSTNAME> ',' <PORT> ',' <STARTCODE>. 1502
removes heartbeats. RS volunteers port and startcode. Master tells it what
its hostname is. Thereafter, RS uses the 'String' the Master gave it for
registering itself in ZK and for passing the master its load ever-after.
This was how 0.90.x was supposed to work but it the above protocol used
HServerAddress which does a lookup on each deserialization. Now we just uses
Strings to identify with startcode serving as a sort-of UUID but with the the
ServerName human-readable rather than UUID opaque.
If you are game, lets try 1502 before we resort to UUIDs? Agree though that
identity loss, theft, and change has made for way too much grief over the life
of hbase.
> Unique transient names for processes
> ------------------------------------
>
> Key: HBASE-3775
> URL: https://issues.apache.org/jira/browse/HBASE-3775
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Andrew Purtell
>
> HBASE-3772 is the latest of several incidents where regionservers and master
> map their identities to hostnames yet hostname resolution is inconsistent
> cluster wide. With HBase 0.20 we have seen this lead conditions like META
> being hosted on 11 servers at once. The situation with HBase 0.90 is better
> but it concerns me a lot. Confusion about identity cannot be anything but bad.
> Why don't we have the processes generate for themselves a random UUID upon
> startup, or similar, and have all processes on the cluster map these UUIDs to
> identities? Critically, region assignment state should hold the UUID of the
> current assignee. This would not remove the need to resolve region locations
> to network addresses, nor determine liveness of assignments, but will prevent
> the specific double assignment scenarios we have seen if hostname resolution
> is flaky.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
