Re: FlinkKafkaProducer 开启Excatly Once之后 初始化事务状态超时的问题

[Wesley Peng]

Hi

on 2019/9/2 11:49, 陈赋赟 wrote:

2019-09-02 10:24:28,599 INFO  org.apache.flink.runtime.taskmanager.Task
 - Interval Join -> Sink: Unnamed (1/4) 
(e8b85b6f144879efbb0b4209f226c69b) switched from RUNNING to FAILED.
org.apache.kafka.common.errors.TimeoutException: Timeout expired while 
initializing transactional state in 6ms.


You may reference this:

https://stackoverflow.com/questions/54295588/kafka-streams-failed-to-rebalance-error

Possible options:

As this answer says, switch off Exactly Once for your streamer. It then 
doesn't use transactions and all seems to work ok. Not helpful if you 
require EOS or some other client code requires transactions.
restart any brokers that are reporting warnings to force them to 
re-resolve the IP address. They would need to be restarted in a way that 
they don't change IP address themselves. Not usually possible in kubernetes.
Defect raised Issue KAFKA-7958 - Transactions are broken with kubernetes 
hosted brokers


Update 2017-02-20 This may have been resolved in Kafka 2.1.1 (Confluent 
5.1.2) released today. See the linked issue.

Re:FlinkKafkaProducer 开启Excatly Once之后 初始化事务状态超时的问题

[陈赋赟]

2019-09-02 10:24:28,599 INFO  org.apache.flink.runtime.taskmanager.Task 
- Interval Join -> Sink: Unnamed (1/4) 
(e8b85b6f144879efbb0b4209f226c69b) switched from RUNNING to FAILED.
org.apache.kafka.common.errors.TimeoutException: Timeout expired while 
initializing transactional state in 6ms.



在 2019-09-02 11:29:35，"陈赋赟"  写道：

我在flink中使用了kafkaProducer 
并开启了ExcatlyOnce语义，第一次部署在测试环境启动的时候一切正常，然后我再上新版本的时候kill掉了之前的任务，并重现发布了一下，就出现了如下的问题日志里显示在做checkpoint的时候出现了初始化事务状态
 超时过期的异常。
具体异常如下：
 


checkpoint interval设置了30s执行一次
producer事务超时（transaction.timeout.ms）时间设置了5分钟




 

FlinkKafkaProducer 开启Excatly Once之后 初始化事务状态超时的问题

[陈赋赟]

我在flink中使用了kafkaProducer 
并开启了ExcatlyOnce语义，第一次部署在测试环境启动的时候一切正常，然后我再上新版本的时候kill掉了之前的任务，并重现发布了一下，就出现了如下的问题日志里显示在做checkpoint的时候出现了初始化事务状态
 超时过期的异常。
具体异常如下：
 


checkpoint interval设置了30s执行一次
producer事务超时（transaction.timeout.ms）时间设置了5分钟

FLINK WEEKLY 2019/35

[Zili Chen]

FLINK WEEKLY 2019/35 

FLINK 社区正在如火如荼的开发 1.10 的新特性中，许多对 FLINK
现有局限的讨论，包括功能上的、配置上的和文档上的问题都在热烈的讨论中。上周，user-zh
列表活跃度大大增加，社区的开发者和使用者对用户的问题的回复也非常迅速，FLINK 中文社区的壮大有目共睹。本周仍然分为用户列表的问答，FLINK
开发的进展和社区事件三个部分为大家推送上周的 FLINK 社区新闻。
USER

flink 1.9 消费kafka报错


实际问题是使用 BLINK planner 的问题，阿里的开发者介绍了使用 BLINK planner 的姿势。

flink1.9 blink planner table ddl 使用问题

flink1.9
Blink planner create view 问题


同样是 BLINK planner 的使用姿势问题。

关于elasticSearch table sink 构造过于复杂


查询结果输出到 ES sink 的连接方式。

关于flink状态后端使用Rocksdb序列化问题


升级到 FLINK 1.8 使用 POJO Scheme Evolution 支持状态模式演化。

Checkpoint使用


作业从 Checkpoint 而不是 Savepoint 中恢复的方式，恢复时可以在一定程度上调整并行度。

FLINK 1.9 Docker 镜像 

FLINK 1.9 Docker 镜像已经发布，包括 Scala 2.11 和 2.12 的支持版本。

How can TMs distribute evenly over Flink on YARN cluster?


FLINK 目前无法保证在 YARN 上起作业的时候 TM 尽量分配到不同的节点上。

type error with generics


FLINK Java API 使用时有时需要手动添加类型信息，在 Scala 的情况下由于有 implicit 所以有时候两种 API 的表现很不相同。

Re: Flink operators for Kubernetes


k8s 上的 FLINK operator 已经由 Apache Beam 社区的成员开发出来了，有 FLINK on k8s 需求的同学可以尝试使用。

Is there Go client for Flink?


目前 FLINK 只有 Java Client 和 REST API，使用 Go 的用户可以通过 REST API 来控制 FLINK
作业的提交和监控。

How to handle Flink Job with 400MB+ Uberjar with 800+ containers ?


FLINK 大作业包含大的 uberjar 的情况下的最佳实践，主要受限于 FLINK Resource Manager
的一些缺陷。阿里和腾讯的开发者都分享了自己处理大作业大包的方案。
DEV

[DISCUSS] FLIP-57 - Rework FunctionCatalog


Bowen Li 的 FLIP-57 旨在提供更好的 FLINK SQL 的开发和编写体验。

[DISCUSS] FLIP-60: Restructure the Table API & SQL documentation


Timo Walther 的 FLIP-60 旨在将 Table API & SQL 的文档从原来附属于 DataStream API
的情况提升为第一层级的文档。FLINK 的用户很多都通过编写 SQL 来实现自己的作业，文档的提升有助于改善用户开发时查阅相关信息的体验。

[DISCUSS] FLIP-59: Enable execution configuration from Configuration object


Dawid Wysakowicz 的 FLIP-59 与 FLIP-54 关系紧密，都是着重在改善 FLINK 的配置情况。目前，FLINK 的
execution configuration 只能在编写程序的时候从程序中设置，与其他许多配置可以通过配置文件或命令行参数等方法传递不一致。

[DISCUSS] Simplify Flink's cluster level RestartStrategy configuration


Till Rohrmann 发起了简化 FLINK 集群级别重启策略配置的讨论，目前 FLINK
的重启策略配置在演化过程中变得很复杂，主要是除了推荐的 restart-strategy 配置外还有非常多的默认行为。

Re: [DISCUSS] Flink client api enhancement for downstream project


Kostas Kloudas 更新了 Client API 重构的进展，按照开发文档实现 JobClient 和多部署后端的 Executor
的原型已经在开发中。
NEWS

[ANNOUNCE] Apache Flink-shaded 8.0 released


Apache Flink-shaded 8.0 发布，Chesnay Schepler 是本次的 release manager，这个项目为
FLINK 提供了 shaded 的依赖。

[DISCUSS] Releasing Flink 1.8.2


jincheng sun 发起了 FLINK 1.8.2 的发布讨论，有望在近期发布 1.8.2 版本。

Best,
tison.

查看调度到 Task Manager 的 Job

[163]

Dear community

Flink 是否提供了从 TaskManager 的角度查看有哪些任务运行在该 TaskManger 的方法？？？


背景：
Flink 1.7.0 版本，Flink on YARN
集群中某一个节点突然负载变高，需要定位哪一个 Job 占用了大量的资源，当前的办法是在 UI 的 Running Jobs 
菜单，一个一个任务去找，然而我们有几十个 Job。快疯了……

Re: Re:使用flink 1.8.1 部署yarn集群 ， 始终有报错

[Yun Tang]

Hi

向0.0.0.0:8030 尝试提交作业是因为提交作业时找不到正确的YARN配置，就会向默认的本地8030端口提交，检查一下HADOOP_CONF_DIR 
或者 HADOOP_HOME 这些环境变量有没有设置正确。可以设置一下这些配置文件的目录地址就可以提交作业了。

BTW，这个不是一个Flink的问题，是所有使用YARN管理作业的大数据计算引擎都有可能遇到的问题。

祝好
唐云

From: 周��岗 
Sent: Sunday, September 1, 2019 15:31
To: user-zh@flink.apache.org 
Subject: Re:使用flink 1.8.1 部署yarn集群 ， 始终有报错


比较肯定yarn的配置基本是正确的，不知道为何flink始终在通过0.0.0.0 连接yarn scheduler







在 2019-09-01 13:55:50，"周��岗"  写道：
>Retrying connect to server: 0.0.0.0/0.0.0.0:8030. Already tried 0 time(s); 
>retry policy is RetryUpToMaximumCountWithFixedSleep
>
>
>
>
>同样的一台电脑使用1.7.2部署就没有问题，有没有大神帮忙看看哪里有问题

Re:使用flink 1.8.1 部署yarn集群 ， 始终有报错

[周虓岗]

比较肯定yarn的配置基本是正确的，不知道为何flink始终在通过0.0.0.0 连接yarn scheduler







在 2019-09-01 13:55:50，"周虓岗"  写道：
>Retrying connect to server: 0.0.0.0/0.0.0.0:8030. Already tried 0 time(s); 
>retry policy is RetryUpToMaximumCountWithFixedSleep
>
>
>
>
>同样的一台电脑使用1.7.2部署就没有问题，有没有大神帮忙看看哪里有问题