SeqQueue内存泄露问题处理

[perrie625]

这个是pomelo就遗留的问题

后端服务handler请求后，在处理请求前，filters.handler.serial.ts: before 函数会为每个session创建一个SeqQueue来保证请求的顺序执行。

但是这个Queue的销毁只在前端服务触发 onSessionClose 时里会调用 closeQueue，后端服务的Queue会一直存在。

每个会话只要有一次请求过某个后端服务的Handler请求，就会多一个Queue，如果长时间运行服务，这个服务内存占用就会不断增长。

目前我的处理是：

在业务代码层面，给需要的后端服务编写一个销毁Queue的remote接口，在前端会话断开连接时，调用这个接口来关闭Queue。

建议：

我觉得pinus可以在 common.remote.backend.msgRemote 里增加一个类似功能的接口，然后在components.connector的 onSessionClose 函数里给为每个后端服务调用一下这个关闭接口

[whtiehack]

的确是个bug，问题在那个 task manager里面。 还好，问题不是很大，影响也不是很大。
只是想要完美解决不要好好研究研究。

[whtiehack]

把 CLOSE_SESSION这个事件透传到后端进程怎么样？而不是只处理这个关闭queue的功能。

[perrie625]

把 CLOSE_SESSION这个事件透传到后端进程怎么样？而不是只处理这个关闭queue的功能。

@whtiehack
可以，不错的想法

[ddk2222-luck]

把 CLOSE_SESSION这个事件透传到后端进程怎么样？而不是只处理这个关闭queue的功能。

@whtiehack
可以，不错的想法

请问这个功能更新了吗?我在代码里好像没有看到此部分的更新?
我现在自己改的也是类似QianPeili的办法解决.

看源代码的时候,似乎好像有一个问题,就是多frontend的时候,每个链接到的frontend的sessionId都是从启动后按1开始累加的

那这个sid不区分frontend前端ID的话,在manager.addTask里

这个时候如果frontend 01和02都生成的SID的话,随便一个关闭都会影响到另外一个前端的回调

[whtiehack]

请问这个功能更新了吗?我在代码里好像没有看到此部分的更新?

 没有针对这个的更新. 因为影响不大,暂时没有时间研究,需要想个好点解决方法

---

看源代码的时候,似乎好像有一个问题,就是多frontend的时候,每个链接到的frontend的sessionId都是从启动后按1开始累加的

是从1开始加的.

sid

这个sid 就是 session的id,从1开始加的, 传到后端的 session 里的id也是这个id.是一个连接的标识.

关闭他只是关闭他一个, 不会影响到其它session.

[ddk2222-luck]

我在后端的remote多加了一个远程RPC调用

exports.RPCGameCloseQueue = function(queueId, cb){
taskManager.closeQueue(queueId, true);
cb(queueId);
}

node_modules/pomelo/lib/connectors/hybridconnector.js
里的“disconnect”事件里在调用这个远程RPC方法，用了半年多了很稳定
app.rpc.hall.gameServerRemote.RPCHallCloseQueue.toServer('*', queueId, function(err){

});

[whtiehack]

监听session的close事件就可以了 不一定要加到框架里. 我们是这样的