发现在压力大的时候handle数量和发出去的消息数量不一致

[arden]

我在看你的文章的时候，发现有人提到这个问题，请问这个问题现在解决了吗？

[leesper]

暂时还没有呢，我最近实在是忙的一塌糊涂……

[piaohailin]

很想知道在什么数量级下发生这个问题的？

[leesper]

@piaohailin 这个要到简书上去找找那哥们，给他留言，问下他压测怎么做的，在多大压力下发现这个问题的

[leesper]

@arden @piaohailin

Hi all，简书上楚客提到的两个问题我今天都一并处理了，具体采取的处理方式如下：

1. 关于ErrWouldBlock问题，我觉得就算把工作者线程数量和buffered channel的size改得再高，总有撑不住的压力，所以我添加了两个新的ServerOption，一个叫WorkerSizeOption，一个叫LoadIndicatorOption。WorkerSizeOption用来调整工作者线程池大小，LoadIndicatorOption用来指定各buffered channel size的倍数（比如指定为2那么size=1024 × 2）。然后我在handleLoop中把返回的err打一个log出来，而不是直接忽略掉。如果循环调用put直到成功，会阻塞事件循环，且不知道阻塞多久能恢复，风险不可控。与其这样，还不如打印日志，让开发者知道问题，并采取措施（比如调整线程池数量或者增加channel的size），这样顺便也把WriteCloser接口的Write方法返回ErrWouldBlock的问题解决了，简单说就是“留给框架使用者去考虑”。

2. 当serverConn关闭时调用asyncWrite不会返回错误的问题的确是一个隐藏的很深的bug，这个我借鉴 楚客的方法做了修改。

[robinbing123456]

DeserializeDeviceMessage这个方法接收数据的时候会出现

2017/07/19 09:44:38 DEBUG [tao.TypeLengthValueCodec.Decode] (message.go:153) - ---------------------------- 2017/07/19 09:44:41 ERROR [tao.TypeLengthValueCodec.Decode] (message.go:198) - message(type 2122219134) has bytes(943207478) beyond max 8388608

[robinbing123456]

在吗？

[leesper]

你的数据包大小超过8M了？如果框架的Codec不满足你的需求，请自己编写一个，谢谢。

[robinbing123456]

用串口服务器测试工具是可以接收的而且每次发的42个字节

[leesper]

@robinbing123456 那就是你length字段填的代表包大小的数字不对，超过8M了