无人值守的自动 dump(二)

[utterances-bot]

无人值守的自动 dump(二)

http://xargin.com/autodumper-for-go-ii/

[lesismal]

对往本地连接的 write buffer 写数据一定不会卡的假设是有问题的。 既然出问题了，说明在这里对我们的程序进行保护是必要的，修改起来也很简单，给 channel send 加一个超时就可以了。

不涉及广播的业务chan send加超时就可以解决了，涉及广播的业务超时时间再短也是会有积压效应的，一个连接卡个100ms，广播排在它后面的就都得卡，而且其他连接也可能卡，而且这还只是广播一个消息，多个消息，就拥堵致死了。

所以我在 arpc 里，如果超时时间为0，则 select default 去回调业务层 OnOverstock handler，这里 handler 通常是 conn.Close ，让客户端自己重连来解决这个层次的慢连接的问题，因为很多公网业务，谁卡了就踢掉谁。至于内网集群之间的连接，如果拥堵了，则要考虑基础设施升级配置和考虑是否需要增加连接池 size 了来拓宽路面了

[cch123]

对往本地连接的 write buffer 写数据一定不会卡的假设是有问题的。 既然出问题了，说明在这里对我们的程序进行保护是必要的，修改起来也很简单，给 channel send 加一个超时就可以了。

不涉及广播的业务chan send加超时就可以解决了，涉及广播的业务超时时间再短也是会有积压效应的，一个连接卡个100ms，广播排在它后面的就都得卡，而且其他连接也可能卡，而且这还只是广播一个消息，多个消息，就拥堵致死了。

所以我在 arpc 里，如果超时时间为0，则 select default 去回调业务层 OnOverstock handler，这里 handler 通常是 conn.Close ，让客户端自己重连来解决这个层次的慢连接的问题，因为很多公网业务，谁卡了就踢掉谁。至于内网集群之间的连接，如果拥堵了，则要考虑基础设施升级配置和考虑是否需要增加连接池 size 了来拓宽路面了

这个之前是给内部的 mesh 项目做的，没广播需求，主要就是本地那个业务的 java 进程 FGC hang 住了

不过似乎他们后面要做 mq mesh，就有广播了

[lesismal]

对往本地连接的 write buffer 写数据一定不会卡的假设是有问题的。 既然出问题了，说明在这里对我们的程序进行保护是必要的，修改起来也很简单，给 channel send 加一个超时就可以了。

不涉及广播的业务chan send加超时就可以解决了，涉及广播的业务超时时间再短也是会有积压效应的，一个连接卡个100ms，广播排在它后面的就都得卡，而且其他连接也可能卡，而且这还只是广播一个消息，多个消息，就拥堵致死了。 所以我在 arpc 里，如果超时时间为0，则 select default 去回调业务层 OnOverstock handler，这里 handler 通常是 conn.Close ，让客户端自己重连来解决这个层次的慢连接的问题，因为很多公网业务，谁卡了就踢掉谁。至于内网集群之间的连接，如果拥堵了，则要考虑基础设施升级配置和考虑是否需要增加连接池 size 了来拓宽路面了

这个之前是给内部的 mesh 项目做的，没广播需求，主要就是本地那个业务的 java 进程 FGC hang 住了

不过似乎他们后面要做 mq mesh，就有广播了

曹大多发发力，借着 java 掉链子机会多干掉 java 项目