[
https://issues.apache.org/jira/browse/HADOOP-20018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jose Luis López updated HADOOP-20018:
-------------------------------------
Description:
*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.
was:
*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 by an end-to-end test of an HA cluster built from trunk.
> 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
>
> *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
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
