目前的场景,服务端开启一个http服务,服务端向客户端以SSE(Server-sent Events)方式发送数据,当客户端主动断开连接,服务端的数据还在持续发送,这时候同一个客户端再次连接会连接不上,观察发现只有SSE发送完成之后才会触发onClose、同一个客户端才能再次建立连接。
我现在需要的时当同一个客户端主动断开连接后,服务端允许同一个客户端马上重新建立连接且不影响之前连接的数据处理,请问有什么好的方法呢?
发重现问题的代码,包括客户端和服务端,要精简的可运行代码
服务端http进程采用的是文档里自定义进程的逻辑( https://www.workerman.net/doc/webman/process.html ),调用$connection->send()向客户端发送数据。 发现config/process.php里count=1时,同一个客户端主动断开几秒然后再次连接时,因上一个连接的sse响应还未结束,所以一直处于连接中状态,等上一个连接的程序跑完了,旧连接上了; 现在count>1时,倒是不会出现这种情况,算是暂时解决了。
发送的数据量比较大?
应该是你写法有问题,把进程卡住了。业务不要用死循环,不要用sleep
目前数据量不大(产品还在测试阶段),也没有死循环,没用sleep。 倒是有一个递归调用外部接口的逻辑,但也加了递归次数限制,不会陷入死循环。 通过观察发现,客户端断开连接之后,sse的输出(打字机效果)结束之后才会调用onClose
那就是进程一直在运行递归调用接口逻辑,workerman内核无法得到运行权,没办法响应新的连接事件
发重现问题的代码,包括客户端和服务端,要精简的可运行代码
服务端http进程采用的是文档里自定义进程的逻辑( https://www.workerman.net/doc/webman/process.html ),调用$connection->send()向客户端发送数据。
发现config/process.php里count=1时,同一个客户端主动断开几秒然后再次连接时,因上一个连接的sse响应还未结束,所以一直处于连接中状态,等上一个连接的程序跑完了,旧连接上了;
现在count>1时,倒是不会出现这种情况,算是暂时解决了。
发送的数据量比较大?
应该是你写法有问题,把进程卡住了。业务不要用死循环,不要用sleep
目前数据量不大(产品还在测试阶段),也没有死循环,没用sleep。
倒是有一个递归调用外部接口的逻辑,但也加了递归次数限制,不会陷入死循环。
通过观察发现,客户端断开连接之后,sse的输出(打字机效果)结束之后才会调用onClose
那就是进程一直在运行递归调用接口逻辑,workerman内核无法得到运行权,没办法响应新的连接事件