我最近在kubernetes集群中将我的Apache Flink升级到1.11版,但今天我发现一个任务检查点总是失败。此任务从RabbitMQ读取数据并计算结果并调用HTTP请求将数据保存到MySQL。这是任务管理器错误日志输出:
2020-08-21 15:53:28
org.apache.flink.util.FlinkRuntimeException: Exceeded checkpoint tolerable failure threshold.
at org.apache.flink.runtime.checkpoint.CheckpointFailureManager.handleJobLevelCheckpointException(CheckpointFailureManager.java:66)
at org.apache.flink.runtime.checkpoint.CheckpointCoordinator.abortPendingCheckpoint(CheckpointCoordinator.java:1626)
at org.apache.flink.runtime.checkpoint.CheckpointCoordinator.abortPendingCheckpoint(CheckpointCoordinator.java:1603)
at org.apache.flink.runtime.checkpoint.CheckpointCoordinator.access$600(CheckpointCoordinator.java:90)
at org.apache.flink.runtime.checkpoint.CheckpointCoordinator$CheckpointCanceller.run(CheckpointCoordinator.java:1736)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
这是Apache FlinkUI错误消息:
Failure Message: Checkpoint expired before completing.
工作总是在一段时间内重新启动。我有2个任务,另一个任务检查点保持成功。那么问题出在哪里,我应该怎么做才能解决这个问题?
这是我的flink配置:
public static void initEnv(StreamExecutionEnvironment env) {
env.setParallelism(1);
env.enableCheckpointing(10000);
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(1000);
env.getCheckpointConfig().setCheckpointTimeout(10000);
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);
env.getCheckpointConfig().enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
StateBackend stateBackend = new FsStateBackend("file:///opt/flink/data");
env.setStateBackend(stateBackend);
}
尝试增加检查点的超时时间:
public static void initEnv(StreamExecutionEnvironment env) {
env.setParallelism(1);
env.enableCheckpointing(120000);
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(1000);
env.getCheckpointConfig().setCheckpointTimeout(120000);
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);
env.getCheckpointConfig().enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
StateBackend stateBackend = new FsStateBackend("file:///opt/flink/data");
env.setStateBackend(stateBackend);
}
问题内容: 有谁知道我可以查看的方式或资源来检查任务计划程序中所有Windows任务的状态?我想看看是否看到任务失败或成功。我想在Python中做到这一点。 我已经看过一些使用win32com.client模块的信息。我可以看到什么任务,但是找不到完成的工作的状态。 问题答案: 以下内容使用Task Scheduler API来打印所有已注册任务的基本信息,包括最后的运行时间和结果。 这仅从列表中
我正在使用executorservice,每个webservice调用都会产生大约9-10个可调用任务,并提交给executorservice线程池。线程池大小为100的应用程序只有一个executorService。当我提交调用时,我有一个2 For循环。外部循环运行到指定的超时期满或完成的散列集大小==提交的任务大小;内部循环将遍历调用项,如果isDone()==true,则将这些调用项收集到
当我运行Android Studio时,会多次出现以下消息: 应用程序安装失败 安装失败,并显示消息无法完成会话:INSTALL _ PARSE _ Failed _ NO _ CERTIFICATES:无法从/data/app/vmdl 1180297295 . tmp/11 _ app-debug使用APK签名方案v2: SHA-256内容摘要未通过验证。 通过卸载现有版本的apk(如果存在)
我正在kubernetes中运行一个Flink作业。我的设置如下 1个作业管理器吊舱 我的flink作业从kafka源获取时间序列数据(时间、值),进行聚合和其他转换,并将其发布到kafka接收器。 有时,我的作业因检查点异常(10分钟后超时)而失败,主要是由一名操作员完成的。我不理解异步持续时间(在图中)的含义,为什么它花费的时间最长。在这个异常之前,Kafka的吞吐量非常高,有500-800万
我们正在尝试使用RocksDB后端设置Flink有状态作业。我们使用会话窗口,有30分钟的间隔。我们使用aggregateFunction,所以不使用任何Flink状态变量。通过采样,我们的事件数不到20k次/秒,新会话数不到20-30次/秒。我们的会议基本上收集了所有的事件。会话累加器的大小会随着时间而增大。我们总共使用了10G内存和Flink1.9,128个容器。以下是设置: 从我们对给定时间
我已经在用Flux查询一些外部资源了。使用()。现在我想实现一种乐观锁定:在查询开始执行之前读取一些状态,并检查它是否在查询完成后更新。如果是这样,抛出一些异常以中断http请求处理。 我通过使用doOnComplete实现了这一点: 我的问题: 正确吗?是否保证在通量之前完成第一个λ。使用(),是否保证在之后严格执行第二个doOnCompletelambda 是否存在更优雅的解决方案