fibbery
我感觉这个可以自定义在listener配置比较好，可能某些自定义rpc协议，一个echo请求就超过了128B这样
https://github.com/mosn/mosn/blob/aecc93c4b2b4801e7992387f245fe9eefa45733d/pkg/server/handler.go#L668 不过我看见处理连接的时候，有传入PerConnBufferLimitBytes，这个是在listener配置的，但不支持json序列化。是否可以复用这个配置的
看起来这参数没使用的地方，废弃了？ taoyuanyuan ***@***.***> 于2022年8月16日周二 12:43写道： > 我们是需要一个默认buffer配置，但这个值看起是限制大小的，有点不匹配的感觉 > > — > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > You...
好的 taoyuanyuan ***@***.***> 于2022年8月16日周二 14:36写道： > 在go的场景下看起来没啥用，我们可以新搞一个连接默认buffer大小的配置项。 > > — > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > You...
websockt啊
> 这么改的话，会不会有就默认值的问题呢？ 比如现在的逻辑是：用户没有配置，我们也默认有 3 次重试？ 我觉得就是正常场景，这个重试的策略就应该由用户自己去定义，而不应该给默认给重试三次。由用户选择性的做，而不应该强制做。 譬如目前的代码，我也无法控制只重试一次，也无法控制不重试
我觉得可以，retryPolicy不为nil则该值设置的重试次数，反之使用默认设置的3次 罗泽轩 ***@***.***> 于 2023年6月12日周一 20:36写道： > 可以设置成，一旦有用户配置的重试次数，那么就以用户的配置为准？ > > — > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . >...
>  有个问题是，这是来自 json 的配置，默认就是 0 呢 最好是，新增一个配置项，来改变这个行为，更加保险一些 我觉得是 1. 默认行为，用户并不会主动配置这个RetryPolicyConfig吧，那实际上RetryPolicy就是nil的，那就用默认的3次配置 2. 如果用户配置了重试策略，我理解他知道配置的作用，那就按照他自定义的做处理吧
感觉新增配置项，理解成本会增高
> > 2. 如果用户配置了重试策略，我理解他知道配置的作用，那就按照他自定义的做处理吧 > > 这里有问题呢，用户原来配置 RetryPolicyConfig，但是没有配置 num_retries，原来的逻辑是默认三次呢 如果直接改就是 0 了呢 > > 如果没有历史负担，我是倾向于直接改的，但是有历史负担，还是要考虑下权衡，其实也是不太好权衡的 我觉得这种可能性小，他既然到知道用配置了，肯定是知道重试机制的，不存在不配置次数吧，这个配置一共也没几个配置项