[
https://issues.apache.org/jira/browse/HADOOP-20018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133464#comment-18133464
]
ASF GitHub Bot commented on HADOOP-20018:
-----------------------------------------
ayushtkn commented on code in PR #8873:
URL: https://github.com/apache/hadoop/pull/8873#discussion_r4398198740
##########
hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/ha/TestZKFailoverController.java:
##########
@@ -137,6 +139,27 @@ public void testNoZK() throws Exception {
runFC(svc));
}
+ @Test
+ public void testBindExceptionIsNotMaskedWhenZkfcRpcServerFailsToStart()
+ throws Exception {
+ DummyHAService svc = cluster.getService(1);
+ assertEquals(0, runFC(svc, "-formatZK"));
+
+ try (ServerSocket occupiedSocket = new ServerSocket(0, 1,
+ java.net.InetAddress.getByName("127.0.0.1"))) {
Review Comment:
import rather than `java.net`
> ZKFC exits with a NullPointerException that hides the BindException when its
> RPC port is in use
> -----------------------------------------------------------------------------------------------
>
> Key: HADOOP-20018
> URL: https://issues.apache.org/jira/browse/HADOOP-20018
> Project: Hadoop Common
> Issue Type: Bug
> Components: ha
> Affects Versions: 3.6.0
> Reporter: Jose Luis López
> Priority: Minor
> Labels: pull-request-available
> Attachments: hadoop20018.sh
>
>
> *Problem*: when the ZKFC cannot bind its RPC port ({{dfs.ha.zkfc.port}}, 8019
> by default), for example because another ZKFC or a stale process holds it, it
> exits with a NullPointerException. The BindException that explains the
> failure is logged once, but the exit status and the final error both name the
> NullPointerException:
> {noformat}
> ERROR org.apache.hadoop.ha.ZKFailoverController: The failover controller
> encounters runtime error:
> java.net.BindException: Problem binding to [localhost:8019]
> java.net.BindException: Address already in use; For more details see:
> http://wiki.apache.org/hadoop/BindException
> Caused by: java.net.BindException: Address already in use
> ERROR org.apache.hadoop.hdfs.tools.DFSZKFailoverController:
> DFSZKFailOverController exiting due to earlier exception
> java.lang.NullPointerException: Cannot invoke
> "org.apache.hadoop.ha.ZKFCRpcServer.stopAndJoin()" because "this.rpcServer"
> is null
> INFO org.apache.hadoop.util.ExitUtil: Exiting with status 1:
> java.lang.NullPointerException: Cannot invoke
> "org.apache.hadoop.ha.ZKFCRpcServer.stopAndJoin()" because "this.rpcServer"
> is null
> {noformat}
> *Cause*: in {{ZKFailoverController.doRun()}}, {{initRPC()}} throws before
> {{rpcServer}} is assigned (the {{ZKFCRpcServer}} constructor fails to bind),
> and the {{finally}} block calls {{rpcServer.stopAndJoin()}} without a null
> check. The NullPointerException thrown from {{finally}} replaces the
> BindException in flight, so {{DFSZKFailoverController}} reports and exits
> with the NullPointerException.
> *To reproduce*: two namenodes of one HA nameservice on the same host without
> a distinct {{dfs.ha.zkfc.port}} each, then start both ZKFCs. The second one
> fails as above. (Any process listening on 8019 does the same.)
> *Proposed fix*: in the {{finally}} block of {{doRun()}}, call
> {{rpcServer.stopAndJoin()}} only when {{rpcServer}} is not null (the
> {{healthMonitor}} next to it already has that check), so the BindException
> reaches the caller and the exit message. A unit test can occupy the ZKFC port
> with a {{ServerSocket}} before starting the controller and assert that the
> exception reported is the BindException.
> *Related*: HADOOP-18831 reports the same unchecked
> {{rpcServer.stopAndJoin()}}, reached through a misconfigured
> {{ipc.server.handler.queue.size}}; HADOOP-18811 another way {{rpcServer}} can
> end up null. This issue is the operational case: a port conflict, where the
> hidden BindException is what an operator needs to see. The same null check
> fixes all three paths.
> Found during the Jetty 12 (EE8) migration testing (HADOOP-19912), by an
> end-to-end test of an HA cluster built from trunk. The bug is on trunk
> itself; the migration does not cause it.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
