[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HDFS HA issue in Flink 1.4 caused by failing to use fs.hdfs.hadoopconf in Flink conf

Another thing: when you retry this again with Flink 1.3.2 it works? I'm trying to rule out another problem in the setup.

On 4. Oct 2018, at 15:17, Aljoscha Krettek <aljoscha@xxxxxxxxxx> wrote:

Hi Yan,

This seems to be a bug in the FileSystems and how they're initialized. I'm looking into this myself but I'm also looping in Stephan and Stefan how have worked on this the most in the past. Maybe they have some valuable input.


On 4. Oct 2018, at 01:18, Yan Yan <yanyan300300@xxxxxxxxxx> wrote:


We recently bumped to Flink 1.4 from 1.3.2, and found out an issue on HDFS configuration.

We are using FlinkYarnSessionCli to start the cluster and submit job.

In 1.3.2, we set below Flink properties when using checkpoints:
state.backend.fs.checkpointdir = hdfs://nameservice0/.../..
state.checkpoints.dir = hdfs://nameservice0/../..

The mapping between logical nameservice (nameservice0) and actual namenodes hostports are passed to Flink via yarnship/core-site.xml (by providing the -yt option), and set fs.hdfs.hadoopconf=yarnship/

However, we encountered below error after bumping to 1.4, which caused the checkpointing to fail.

2018-09-20 01:01:00.041 [yarn-jobmanager-io-thread-18] WARN  org.apache.flink.runtime.checkpoint.OperatorSubtaskState  - Error while discarding operator states. Cannot instantiate file system for URI: hdfs://nameservice0/app/athena_checkpoint/rt_data/gairos-athena-flink-demand-processor-opticclient-flink-job/flink/checkpoints/ckpt_1537402213581/data/ebb30a2d3b26e4d63682538a9bcdc752/chk-3204/da1d44d3-d3eb-4e57-9145-bdf30c96993a
    at org.apache.flink.runtime.fs.hdfs.HadoopFsFactory.create(
    at org.apache.flink.core.fs.FileSystem.getUnguardedFileSystem(
    at org.apache.flink.core.fs.FileSystem.get(
    at org.apache.flink.runtime.state.filesystem.FileStateHandle.getFileSystem(
    at org.apache.flink.runtime.state.filesystem.FileStateHandle.discardState(
    at org.apache.flink.runtime.state.OperatorStateHandle.discardState(
    at org.apache.flink.util.LambdaUtil.applyToAllWhileSuppressingExceptions(
    at org.apache.flink.runtime.state.StateUtil.bestEffortDiscardAllStateObjects(
    at org.apache.flink.runtime.checkpoint.OperatorSubtaskState.discardState(
    at org.apache.flink.runtime.checkpoint.OperatorState.discardState(
    at org.apache.flink.util.LambdaUtil.applyToAllWhileSuppressingExceptions(
    at org.apache.flink.runtime.state.StateUtil.bestEffortDiscardAllStateObjects(
    at org.apache.flink.runtime.checkpoint.PendingCheckpoint$
    at java.util.concurrent.ThreadPoolExecutor.runWorker(
    at java.util.concurrent.ThreadPoolExecutor$
Caused by: java.lang.IllegalArgumentException: nameservice0
    at org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(
    at org.apache.hadoop.hdfs.NameNodeProxies.createProxy(
    at org.apache.hadoop.hdfs.DFSClient.<init>(
    at org.apache.hadoop.hdfs.DFSClient.<init>(
    at org.apache.hadoop.hdfs.DistributedFileSystem.initialize(
    at org.apache.flink.runtime.fs.hdfs.HadoopFsFactory.create(
    ... 15 common frames omitted
Caused by: nameservice0
    ... 22 common frames omitted

It does not recognize nameservice0 because the core-site.xml on the actual machine (read in by Flink via $HADOOP_CONF_DIR) does not use nameservice0 but something else for the fs.defaultFs

Digging a little bit, I found that the hadoopConfig (code) does not have the properties we set via yarnship/core-site.xml. Especially, I suspect it is due to the cached HadoopFsFactory is initialized with an dummy Configuration (code), which prevents future flinkConfig getting passed in (code).

I am not sure if this is intentional, or has been solved in later releases. Has anyone encountered the same problem? And I would appreciate any suggestions.