workerman是否有请求超时时间的概念?

chaz6chez

使用workerman实现了一个多进程的web server,当请求进来时,唤醒其中一个进程执行业务逻辑,在与其他子系统通讯时(如grpc),由于暂时无法实现与grpc的超时断线,很容易内部就形成死进程,这时该子进程保持busy状态,并且无法退出也未有返回,workerman可否定义一个请求超时时长?比如该次请求的业务执行时长超过某个时间定义就自动退出子进程?

4005 2 1
2个回答

静默

手册里好像没看到有关设置workerman超时的东西,估计是没有的

  • chaz6chez 2019-01-10

    额,每个连接建立的时候创建一个定时器,然后连接断掉的时候销毁这个定时器,定时器到时的时候,主动把进程退出。
    我是这么做的,但是感觉这样加重了消耗。
    另外grpc的问题是因为grpc的客户端要在fork之前建立好,之后的话,就会再startBatch中无限等待。

  • chaz6chez 2019-01-10

    说错了,是fork之后建立好

walkor

不要在workerman里fork进程,workerman不支持业务fork进程

  • chaz6chez 2019-01-10

    我的意思是workerman自身做了fork的操作,生成了多个进程,grpc的拓展不支持再fork之后做连接,所以得workerman主流程内做好grpc的链接

  • chaz6chez 2019-01-10

    也就是在入口脚本的Worker::runAll();之前做好对grpc的客户端连接,保存在静态容器里面,之后再做调用就好了

  • walkor 2019-01-10

    这样workerman就控制不到你的进程了,可能会有副作用,比如进程僵死之类的

  • chaz6chez 2019-01-10

    @1:现在出现了一个问题就是我在业务中调用grpc拓展创建客户端,然后执行对应服务的时候会死进程,但是在cli和fpm和windows下没问题,我在怀疑是不是grpc拓展的内部实现和workerman调用的某个拓展起了冲突,大佬有没有使用grpc的经验?

  • walkor 2019-01-10

    没用过grpc

  • chaz6chez 2019-01-10

    找到问题了,workerman使用了pctnl_fork进程,而grpc拓展不支持任何的grpc连接创建在fork之前就创建,单grpc拓展在zend虚拟机启动时就加载了,所以相比worker man的fork就领先了。可以在worker man onStartWork内使用dl函数加载grpc拓展,使用dl函数前请在配置文件中将enable_dl修改为on。
    任何一个使用fork达到多进程目的的程序与grpc交互都可以使用这个思路解决,grpc官方也计划对fork兼容,只是暂时没有实现。
    https://github.com/grpc/grpc/issues/15334

  • 静默 2019-01-15

    学习了

  • jasonyqwang 2021-03-31

    @4967:

  • chaz6chez 2021-10-23

    统一回复,grpc在之后修复了这个问题,可以与workerman共存了

年代过于久远,无法发表回答
🔝