Trino项目优雅停机功能异常分析与修复

在分布式SQL查询引擎Trino的最新版本中，开发团队发现了一个关键性的功能回归问题。该问题涉及系统的优雅停机(Graceful Shutdown)机制，在版本474及后续版本中出现了异常行为，导致正在执行的查询任务无法正常完成。

问题现象

在测试环境中，当管理员通过REST API触发节点停机流程时，系统表现出两种截然不同的行为：

1. 在版本472中，执行中的select count(*)查询能够顺利完成（耗时约6分钟）
2. 在版本474+中，相同查询会在2分钟后失败，并抛出HTTP 500错误

错误日志显示，工作节点在停机过程中过早关闭了HTTP连接，导致协调器无法获取任务状态更新。核心错误表现为：

io.trino.spi.TrinoException: Expected response code from http://.../v1/task/.../status to be 200, but was 500

技术背景

Trino的优雅停机机制设计包含以下关键组件：

1. 停机宽限期：默认配置为2分钟（可通过shutdown.grace-period调整）
2. 状态转换：通过/v1/info/state接口将节点状态置为SHUTTING_DOWN
3. 任务协调：工作节点需保持服务直到所有任务完成或超时

在正常流程中，节点进入SHUTTING_DOWN状态后应该：

• 停止接受新任务
• 继续服务现有任务直至完成
• 在宽限期结束后强制终止

问题根源

通过代码审查和测试验证，团队确认该问题源于PR #25069引入的改动。该PR原本旨在修复一个罕见的竞态条件，但意外影响了HTTP连接的生命周期管理。具体表现为：

1. Jetty服务器在停机过程中过早关闭连接
2. 任务状态更新请求被拒绝（RejectedExecutionException）
3. 线程池异常终止导致回调处理失败

解决方案

开发团队采取了以下措施：

1. 紧急回滚：立即回滚有问题的PR变更，确保即将发布的版本稳定性
2. 测试验证：编写专项测试用例重现并验证修复方案
3. 深度修复：重新设计连接管理逻辑，确保：
   • 停机信号正确传播
   • 现有连接保持活跃直至任务完成
   • 资源释放顺序符合预期

技术启示

该案例为分布式系统开发提供了重要经验：

1. 停机流程测试：需要专门测试各种负载条件下的优雅停机行为
2. 连接生命周期：HTTP连接管理需要与任务生命周期精确协调
3. 变更影响评估：即使针对边缘情况的修复也可能影响核心流程

对于生产环境部署，建议管理员：

• 在升级前验证优雅停机功能
• 根据查询复杂度合理设置宽限期
• 监控停机过程中的任务转移情况

目前修复方案已通过完整测试，将在下个版本中发布。该问题的及时发凸显了Trino社区对系统稳定性的高度重视，以及快速响应机制的有效性。