[Bug]requests lost

[zscomehuyue]

Search before asking

• I had searched in the issues and found no similar issues.

Environment

Linux

EventMesh version

master

What happened

The server core thread pool of Mesh adopts a default dropout strategy; Assuming there is blocking, important requests will be lost;

How to reproduce

The connection between MESH and Rocketmq is disconnected, and the client sends a large number of messages;

Debug logs

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct *

[pandaapo]

The server core thread pool of Mesh adopts a default dropout strategy; Assuming there is blocking, important requests will be lost;

I think this can be optimized by changing the strategy or other ways to reduce the amount of data loss. Would you be willing to submit a PR to fix this?

The connection between MESH and Rocketmq is disconnected, and the client sends a large number of messages;

I think that the situation of disconnected connection should not be considered as "blocking" mentioned above.

[xwm1992]

I think the situation you gave is a message sending failure, not a message loss, because the connection between the mesh and the broker is disconnected, which has nothing to do with the dropout strategy of the thread pool.

---

我认为你举例这种情况属于消息发送失败，并不是消息丢失，因为mesh与broker的连接断开，与线程池的dropout策略没有关系

[zscomehuyue]

当我发送过快消息时，服务端队列1w，会超过该队列时，会触发丢弃策略，EventMeshTcpExceptionHandler的异常处理会触发close session；客户端会进行重新连接；
而被关闭的有可能是订阅session，也有可能是发送session；
感觉服务端丢弃也是合理的，过多的消息，服务端不能及时处理，只有丢弃（放到本地线程执行会影响整体性能）
如果把订阅和发送使用不同线程池，这样发送和订阅就不会相互影响；
改动：

1. MessageTransferTask 使用独立线程池，采用丢弃，关闭session策略，让客户端重新连接；
2. 其他Task采用独立线程池采用本地执行，task过多的是MessageTransferTask发送任务；