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

chaz6chez 更新于2019-01-10

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

 4677  2 3

2个回答

静默 2019-01-09

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

chaz6chez 2019-01-10

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

说错了，是fork之后建立好

walkor 2019-01-10

打赏

不要在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共存了