Lagom Scala运行sbt runAll偶发TimeoutException问题求解

你遇到的java.util.concurrent.TimeoutException根因是Lagom开发模式内置的服务就绪探针基于Akka Streams实现时，设置了默认5秒的初始信号等待窗口，窗口期内未捕获到服务就绪状态就会触发超时，属于开发环境启动性能问题，和已经通过的sbt clean compile编译流程无直接关联。

分步落地方案 #

• 放宽服务就绪探针的超时阈值
  在项目根目录的build.sbt全局构建配置块中追加配置，将默认5秒的等待窗口拉长到30秒，适配JVM冷启动、框架依赖初始化的固有耗时：

  import scala.concurrent.duration._
  
  ThisBuild / lagomServiceTimeout := 30.seconds
  

• 为sbt进程分配稳定的运行内存
  在项目根目录新建.sbtopts配置文件，为sbt后台运行进程分配足够的堆内存，避免启动阶段频繁触发垃圾回收拖慢服务就绪速度：

  -J-Xms1024m
  -J-Xmx2048m
  

• 减少不必要的冷启动开销
  日常开发启动时直接执行sbt runAll即可，无需每次都附加clean参数。clean操作会清空sbt的本地编译缓存、类文件、依赖索引，每次执行都会触发全量依赖加载与全量代码编译，大幅拉长启动耗时，是偶发超时的最常见诱因。仅当出现依赖版本冲突、编译缓存损坏等异常场景时，再使用clean流程即可。
• 适配内嵌Cassandra的启动耗时
  如果项目使用Lagom默认内嵌的Cassandra持久化服务，冷启动阶段Cassandra的初始化过程很容易超出默认等待窗口，可以在对应服务的src/main/resources/application.conf中适当放宽Cassandra的就绪等待时间：

  lagom.cassandra.wait-for-start = 20s
  

快速排查提示 #

这类超时属于非致命的启动提示，触发异常后可以持续观察控制台日志：如果后续日志正常打出某服务的Service started on port XXXX标识，说明服务实际可以正常就绪，仅需调整探针超时阈值即可，无需修改业务逻辑代码。

内容的提问来源于stack exchange，提问作者md sam