[HBASE-15856] Cached Connection instances can wind up with addresses never resolved

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Fix Version/s: 1.3.0, 1.2.2, 0.98.20, 1.1.6, 2.0.0
• Component/s: Client

Release Note

During periods where DNS resolution was not available or not working correctly, we could previously cache unresolved hostnames forever, in some cases preventing further connections to these hosts even when DNS service was restored. With this change, unresolved hostnames will no longer be cached, and will instead throw an UnknownHostException during connection setup.

• Assignee: Gary Helmling
• Reporter: Gary Helmling
• Created: 18/May/16 21:54
• Updated: 31/May/16 13:05
• Resolved: 20/May/16 19:36

Description

During periods where DNS is not working properly, we can wind up caching connections to master or regionservers where the initial hostname resolution and the resolution is never re-attempted. This means that clients will forever get UnknownHostException for any calls.

When constructing a BlockingRpcChannelImplementation, we instantiate the InetSocketAddress to use for the connection. This instance is then used in the rpc client connection, where we check isUnresolved() and throw an UnknownHostException if that returns true. However, at this point the rpc channel is already cached in the HConnectionImplementation map of stubs. So at this point it will never be resolved.

Setting the config for hbase.resolve.hostnames.on.failure masks this issue, since the stub key used is modified to contain the address. However, even in that case, if DNS fails, an rpc channel instance with unresolved ISA will still be cached in the stubs under the hostname only key.

Issue Links

• is duplicated by: HBASE-13960 HConnection stuck with UnknownHostException