业务逻辑是:每天将设备库存不足的信息记录到mysql表中,然后根据用户设置的推送时间段,来进行微信模板消息推送, 业务测试当天无任何问题,第二天 就不推送了。 而这时我直接执行php脚本还是能收到微信推送信息。不知道怎么办咯。。。
第二天查看 status 的情况 [attach]1060[/attach]
日志情况:
[attach]1059[/attach]
定时器使用代码截图
[attach]1058[/attach]
在执行 reload 后,可以继续推送。。。。 这种情况,怎么解决? 难道要每天凌晨reload 一下吗?
升级下workerman试下
好的,我试一下
有什么办法能检测到定时器是否还在运行吗?
向磁盘写日志
目前改 linux 计划任务 隔天 仍正常运行中....
更新了wokerman最新版本后,定时器里跑时间长 仍然还是不执行PHP脚本了。
现在在 计划任务里继续测试中...
可能业务阻塞了,可以用strace 和 lsof 命令配合定位阻塞在哪里
收到。
看到 BusinessWorker 的 exit_count 为 12,貌似有报错退出的情况发生。如果是 timer handler 所在的进程报错的话,将导致进程退出,重启后 worker id 不同,则无法重新设置定时器。
这是 reload 后 出现的报错。 正常的
保险的办法,可以在 timer handler 里面输出 log 以观察是否还活着,同时用 try/catch 捕获所有可能的异常。还不行的话用 register_shutdown_function 看看程序是怎么退出的。
在执行 reload 后,可以继续推送。。。。 这种情况,怎么解决? 难道要每天凌晨reload 一下吗?
升级下workerman试下
好的,我试一下
有什么办法能检测到定时器是否还在运行吗?
向磁盘写日志
目前改 linux 计划任务 隔天 仍正常运行中....
更新了wokerman最新版本后,定时器里跑时间长 仍然还是不执行PHP脚本了。
现在在 计划任务里继续测试中...
可能业务阻塞了,可以用strace 和 lsof 命令配合定位阻塞在哪里
收到。
看到 BusinessWorker 的 exit_count 为 12,貌似有报错退出的情况发生。如果是 timer handler 所在的进程报错的话,将导致进程退出,重启后 worker id 不同,则无法重新设置定时器。
这是 reload 后 出现的报错。 正常的
保险的办法,可以在 timer handler 里面输出 log 以观察是否还活着,同时用 try/catch 捕获所有可能的异常。还不行的话用 register_shutdown_function 看看程序是怎么退出的。