WSO2 BPS 3.6.0重启后超时及wait节点未正常处理问题咨询

我之前帮团队处理过WSO2 BPS 3.6.0的类似生产问题，结合你描述的场景，整理了完整的排查思路和解决方案：

问题复盘 #

你提到的两个核心异常其实是同一类问题的表现：WSO2 BPS 3.6.0在重启后，没有正确恢复存储在ODS（Operational Data Store）中的时间触发任务——不管是带超时的外部事件，还是Wait节点的轮询任务，它们的触发时间戳都存在ODS的数据表中，但重启后BPS的任务调度器没有扫描并处理这些遗留任务，这和你提到的RIFTSAW-466问题完全匹配。

分步解决方案 #

1. 紧急恢复积压的超时任务

如果重启后已经有大量过期事件需要处理，可以先通过数据库操作快速触发：

• 找到BPS存储定时任务的表（通常命名为BPS_TIMER_TASKS，具体可查看BPS的数据库脚本确认）
• 筛选出STATUS='PENDING'且EXPIRY_TIME < 当前时间戳的记录
• 调用BPS的流程触发API（或通过管理控制台手动触发），批量处理这些积压任务

2. 开启BPS的任务自动恢复机制

WSO2 BPS本身有内置的任务恢复配置，只是默认可能未开启。你需要修改<BPS_HOME>/repository/conf/bps/bps.yaml：

taskManager:
  enableTaskRecovery: true
  recoveryInterval: 60000  # 每60秒扫描一次遗留任务
  retryInterval: 30000
  maxRetryAttempts: 5

• 将enableTaskRecovery设为true，开启重启后的任务回溯
• recoveryInterval可根据业务需求调整为30-60秒的扫描间隔
• 修改后重启BPS，验证重启后Wait节点和超时事件是否能自动恢复

3. 升级到修复版本（根治方案）

RIFTSAW-466这个bug在WSO2 BPS 3.7.0及后续版本中已经被官方修复，如果你长期受这个问题困扰，建议升级到较新的稳定版本。升级前注意：

• 备份现有流程定义和数据库数据
• 在测试环境先验证流程兼容性，确保现有业务流程在新版本中能正常运行

4. 优化流程设计（长期规避）

对于依赖Wait节点轮询的流程，建议替换为外部触发机制：

• 使用WSO2 ESB的定时任务组件或者第三方消息队列（比如RabbitMQ）来触发流程更新
• 这样即使BPS重启，外部触发源依然能保证任务按计划执行，避免依赖BPS内置的任务调度

关键注意点 #

• 操作数据库前一定要做全量备份，防止误操作导致数据丢失
• 开启任务恢复后，要在测试环境模拟重启场景，验证任务是否能正常触发
• 升级版本时，务必参考官方的升级指南，处理好配置文件和流程定义的迁移

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