数据流作业因“处理暂停”而停止答案

【问题标题】：Dataflow job halts with "Processing lull"数据流作业因“处理暂停”而停止
【发布时间】：2018-01-29 14:28:48
【问题描述】：

使用会话窗口运行具有相当高级组的流式数据流管道我在运行几个小时后遇到了问题。这项工作在工人中扩大，但后来开始使用以下内容获取日志负载

Processing lull for PT7500.005S in state process of ...

记录此代码的转换就在“分组依据”块之后，并对外部服务执行异步 HTTP 调用（使用 scala.concurrent.{Await/Promise}）。

任何想法为什么会发生这种情况？与异步、扩展或按策略分组有关？

【问题讨论】：

这可能与异步调用 HTTP 服务有关。我遇到过与此相关的类似问题。作为测试，您可以尝试同步调用服务。您不会获得几乎一样高的吞吐量，但您可以确定问题是否与异步调用有关。
可能是您正在通过 HTTP 与之通信的服务器超载？
@Andrew：我肯定会尝试这个，我首先使用异步的原因是为了获得更好的吞吐量和能够使用重试逻辑来处理 http 服务器错误。你有什么好的替代品推荐吗？
@Pablo：嗯，吞吐量相当高，但这应该不是问题，因为我与之交谈的服务会自动缩放到无穷大甚至更远。但是，如果我超载了服务——为什么 beam 会这样呢？
@Brodin，我尝试过的一件事是配置用于ExecutionContextExecutorService 的线程数。这使我能够控制对服务的并发请求数。如果服务超载，我可以减少线程数。不幸的是，对服务的异步调用没有很好的替代品。另一种方法是将服务逻辑包含为转换（即直接调用数据库）。我还尝试在 Node.js 中实现 Dataflow 作业，它是为异步功能而构建的。

【解决方案1】：

@jkff comment 为我指明了正确的方向。第一步是为 scala 未来添加超时 - 这向我展示了“处理暂停”实际上是从未终止的承诺，从而迫使数据流“永远”保持它们。现在我得到了正确的未来超时错误，但无济于事，因为工作仍然没有继续进行。现在改为同步调用，但我发现吞吐量要低得多

【讨论】：