经过确认,基本都是卡在http节点,我当前的http节点访问的不是外网,都是内网的
而且非定时工作流也有同样的http节点,从未有卡住的,只有定时任务的频繁卡在进行中
当前版本:1.3.3-beta
update:
我的定时任务是根据某个表的创建时间延后3分钟,异步
经过确认,基本都是卡在http节点,我当前的http节点访问的不是外网,都是内网的
而且非定时工作流也有同样的http节点,从未有卡住的,只有定时任务的频繁卡在进行中
当前版本:1.3.3-beta
update:
我的定时任务是根据某个表的创建时间延后3分钟,异步
请问是偶发还是必现呢,或者是否能找到必现的条件?
不是必现的,目前我数据量也不大,从我发的图1上看,偶尔会出现;
从图2上可以看出,出现时,HTTP节点会有两次请求似的,正常的都是1次,这很奇怪
我这边先尝试复现一下,如果没有必现条件的话可能会比较难跟踪。
今天又看到新状况,还是这个定时工作流
昨天25号的任务,今天26号了,还显示队列中
都没有开始执行,一直停在这了
看日志的版本,大概是这个原因导致,昨天我复制了#35版本,847已使用了#35,而且#29已停用,怎么后面还会用#29版本,我并未再启用#29
是说原来的版本是 #29,然后复制到新版本是 #35,启用 #35 之后,旧版本 #29 还是触发了?
BTW,如果是未启用的被触发,的确是会在队列中但不会执行。
是的,但在倒数第3条已执行过#35,后面2条怎么会执行未启用的#29,这是不是有问题
这样的确是有问题,我按你说的步骤也复制版本试一下。
我看这个日志的时间,倒数2、3条的时间完全一样,我去确认了一下执行的数据是同一条
也就是说工作流优先用#35执行了一次,然后又用#29执行一次,但卡在队列中
再到下午4点,没再触发#35,直接卡#29 了
暂时解决先重新启用一下这个工作流(还不行的话重启一下应用),我这边继续跟踪一下这种情况。
有什么办法是能必然复现的么?我试了启用新版本也没发现这种情况。能复现就比较容易解决。
另外如果已经重启过了,旧版本的还可以触发的话,需要检查一下数据库 workflows 表里这两行记录,看看 current
和 enabled
两个字段是否有异常。
你的api接口支持并发吗
你可能没有分析我的问题
1,工作流的http节点默认有超时,大概几秒,超时会出错
2,日志显示队列中,而且过去几天了,还在队列中
3,我的api在内网,只用于工作流,一天都不超过20次请求
4,就算有并发问题,请求超时,这个工作流会出错,而不是一直队列中
主要是重复触发的问题。在队列中的都是重复触发出来的,因为该执行计划背后的工作流(版本)已禁用,所以不会被执行,状态也就不改变,这个是合理的。
目前仍在尝试复现定时任务重复触发的问题,如果能有稳定复现的步骤,可以提供一下以助排查。