经过确认,基本都是卡在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
两个字段是否有异常。