Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
0.20.205.0
-
None
-
Reviewed
Description
The current RPC client implementation and the client-side callers assume that the hostname-address mappings of servers never change. The resolved address is stored in an immutable InetSocketAddress object above/outside RPC, and the reconnect logic in the RPC Connection implementation also trusts the resolved address that was passed down.
If the NN suffers a failure that requires migration, it may be started on a different node with a different IP address. In this case, even if the name-address mapping is updated in DNS, the cluster is stuck trying old address until the whole cluster is restarted.
The RPC client-side should detect this situation and exit or try to recover.
Updating ConnectionId within the Client implementation may get the system work for the moment, there always is a risk of the cached address:port become connectable again unintentionally. The real solution will be notifying upper layer of the address change so that they can re-resolve and retry or re-architecture the system as discussed in HDFS-34.
For 0.20 lines, some type of compromise may be acceptable. For example, raise a custom exception for some well-defined high-impact upper layer to do re-resolve/retry, while other will have to restart. For TRUNK, the HA work will most likely determine what needs to be done. So this Jira won't cover the solutions for TRUNK.
Attachments
Attachments
Issue Links
- is related to
-
HDFS-34 The elephant should remember names, not numbers.
- Resolved
- relates to
-
HADOOP-7510 Tokens should use original hostname provided instead of ip
- Closed
-
HADOOP-7492 Add automated test for the RPC IP addr change detection and reconnect feature
- Open