Spring Integration 6.x迁移后Gateway sendAndReceive无回复故障排查求助

核心日志解读 #

1. 临时回复通道超时警告

   WARN o.s.messaging.core.GenericMessagingTemplate$TemporaryReplyChannel - Reply message received but the receiving thread has exited due to a timeout
   这个警告的本质是：等待子流回复的外层线程已经因超时退出，但子流后续完成后仍将回复发送到了临时通道。外层流没有等到回复就提前终止，而子流本身是执行成功的。

2. 网关无回复调试日志

   DEBUG o.s.integration.gateway.GatewayProxyFactoryBean$MethodInvocationGateway - failure occurred in gateway sendAndReceive: No reply produced by handler 'autoScheduledScenarioGroupFlow.org.springframework.integration.config.ConsumerEndpointFactoryBean#3', and its 'requiresReply' property is set to true.
   说明子流中指定的处理器未生成预期回复，且该处理器的requiresReply被设为true。虽然这是调试级别日志，但可能暴露子流内部的消息流转问题，间接导致外层超时。

分步排查方案 #

• 核查超时配置
  6.x版本调整了GenericMessagingTemplate的默认receiveTimeout（从无限等待改为30秒），网关的默认replyTimeout也可能同步变更。检查调用子流的网关配置：

  • 注解方式：@Gateway(replyTimeout = ...)的数值是否覆盖了默认值，是否足够容纳子流异步操作的最长耗时。
  • XML配置：确认<gateway>标签的reply-timeout参数设置。
    如果之前依赖5.x的无限等待默认值，升级后必须显式设置足够长的超时时间。

• 定位无回复的处理器
  针对日志中提到的autoScheduledScenarioGroupFlow.org.springframework.integration.config.ConsumerEndpointFactoryBean#3：

  1. 确认该处理器的类型（服务激活器、过滤器、路由器等）。
  2. 如果该处理器允许不产生回复，将其requiresReply属性设为false；如果必须产生回复，排查消息丢失原因（比如被过滤器拦截、异常被捕获但未返回消息）。

• 检查异步线程池状态
  子流中的异步操作（ExecutorChannel、@Async任务）如果线程池资源不足（核心线程数不够、队列满），会导致任务排队等待，拉长整体处理时间超过超时阈值。查看线程池监控指标（活跃线程数、队列长度），或调整线程池的corePoolSize、maxPoolSize、queueCapacity参数。

• 验证聚合器配置
  外层聚合器的以下配置可能影响结果：

  • sendPartialResultOnExpiry：如果开启，聚合器会在超时后发送部分结果，导致外层流提前终止，后续子流的回复就会触发临时通道警告。
  • expireGroupsUponCompletion：6.x默认值改为true，如果聚合组提前过期，后续回复无法找到对应组，也会触发警告。
  • 确认correlationStrategy和releaseStrategy逻辑是否正常，确保拆分后的所有消息都能被正确聚合。

• 开启TRACE级日志追踪
  开启org.springframework.integration的TRACE级别日志，跟踪消息的correlationId、replyChannel头等关键属性的流转路径，确认每个端点的输入输出，找到回复延迟或丢失的具体环节。

5.x到6.x的关键行为变更 #

• 默认超时调整：GenericMessagingTemplate默认receiveTimeout从-1（无限等待）改为30秒，网关默认replyTimeout同步变更。
• requiresReply默认值：部分场景下，网关和处理器的requiresReply默认值从false改为true，若子流存在可选回复的环节，需显式调整。
• 聚合器默认行为：expireGroupsUponCompletion默认值改为true，聚合组完成后会立即过期，后续无法接收延迟的回复。
• 异步处理优化：ExecutorChannel的默认线程池参数调整，异步消息的传递规则更严格，可能影响任务执行效率。

内容的提问来源于stack exchange，提问作者Piers Geyman