实际测试的时候发现,如果所有的账户都退出离线之后,等十几分钟之后,再次重新登录,需要再命令行把服务重启才能正常通信。
web-msg-sender里用了mysql?
用了,不过是事件触发的时候会用
毕竟要推送消息,肯定是推送后端的数据过去的,这个会有什么问题吗,一直都没有找到解决方案
但是出现这个问题,一般都是在所有的用户都退出离线之后才出现的,为啥过一段时间重新登录之后就不行了呢
mysql服务端会关闭长时间不活跃的mysql连接,所以第二天你的业务就异常了。 web-msg-sender 建议只做推送,不做其它业务。 如果你非要在web-msg-sender里使用mysql,有两种简单的方案。 方案一:每次使用数据库的时候重新连接,使用完毕后关闭数据库连接 方案二:把初始化数据库连接放到onWorkerStart里,并加一个定时器定时 select 1 维持mysql连接通讯,类似
$io->on('workerStart', function() { your_mysql_connect_fun(); Workerman\Timer::add(55, function(){ your_db_query('select 1'); }); };
好的,我现在测试一下,谢谢大佬
好像已经解决了,目前测试了所有用户退出之后五分钟之后重新登录,已经可以正常通讯了,用的就是你说的第一种方案,谢啦,大佬
web-msg-sender里用了mysql?
用了,不过是事件触发的时候会用
毕竟要推送消息,肯定是推送后端的数据过去的,这个会有什么问题吗,一直都没有找到解决方案
但是出现这个问题,一般都是在所有的用户都退出离线之后才出现的,为啥过一段时间重新登录之后就不行了呢
mysql服务端会关闭长时间不活跃的mysql连接,所以第二天你的业务就异常了。
web-msg-sender 建议只做推送,不做其它业务。
如果你非要在web-msg-sender里使用mysql,有两种简单的方案。
方案一:每次使用数据库的时候重新连接,使用完毕后关闭数据库连接
方案二:把初始化数据库连接放到onWorkerStart里,并加一个定时器定时 select 1 维持mysql连接通讯,类似
好的,我现在测试一下,谢谢大佬
好像已经解决了,目前测试了所有用户退出之后五分钟之后重新登录,已经可以正常通讯了,用的就是你说的第一种方案,谢啦,大佬