The Message records byte[] messy code Error decode！ about turms HOT 5 CLOSED

这里注释掉图一代码, 并添加图二方法，即解决了问题，请作者参考一下，并解释一下原因最好，感谢。

明文打印问题出现部分的乱码内容，如下，可以清晰的看到，ClientApiLogging.log 入侵了 返回的数据结构体

from turms.

It should not be the problem of the RPC service because if the RPC service encodes or decodes client messages incorrectly, turms clients will not have the chance to receive the responses and notifications.

I added some system tests about sending and receiving message records on my local computer, and all tests passed.
I also go through the workflow of sending and receiving message records from clients to servers and servers to clients, and they should work fine.

So I cannot reproduce the problems.

If you still encounter the problem, you can debug your clients and Turms servers yourself (that's why Turms is open-source).
After you find a message record is wrong. You can query the message document in MongoDB to check if the message document is stored incorrectly.
If the message record is stored incorrectly, you can debug the encoding and storing processing.
If not, you can debug the decoding processing to find out which step is wrong.
The debugging process should not be hard because you can reproduce the problem on your local, and you have all the source code and data in MongoDB.

from turms.

1、我这边本地环境
windows、mongodb 7.05、使用git仓库develop分支最新代码

2、本地复现，前几次请求同一个消息转码出来的二进制是正确的，如上截图标注了，连续的快速点击按钮十几次后，同一个消息的records部分就会出现乱码。这里再附上一张本地在调试的代码。

from turms.

Thanks for reporting and helping to pinpoint the bug.
I know now why it happens and will publish a bug fix and new release tomorrow or the day after tomorrow.

I will @you once published.

from turms.

@zhaieryuan The bug has been fixed.
You can pull the latest code on the develop or master branch or pull the latest docker image to have a try.

The root cause is the bytes parameters of turms requests may be recycled while the server handler is handling the request. For details, please check the commit: 296afae

from turms.