Bright Chen
Bright Chen
> 是否可以给IOBuf开发一个不共享模式，然后通过memory profiler来定位问题？ 应该是可以的。 当时的IOBuf泄漏问题在测试环境无法复现，只能在线上服务排查。因为（拷贝模式）这个方案可能需要改造BLock、IOBuf及其所有派生类等相关的功能，侵入性大、改动量大、风险大，所以最后没有采用这个方案。
StreamWrite没有返回网络错误，一直返回EAGAIN的话，应该是client挂了，但是server并没有感知到tcp连接断开，发送的数据没有收到client的ack，随后写不进去内核缓冲区后，就一直返回EAGAIN。
idle机制不能解决这个问题。 可能需要借助tcp_user_timeout（#1154）来断开连接。
> 另外brpc::StreamClose也释放不了，对吧。 可以释放的。 > brpc目前还没支持tcp_user_timeout吧 后续提个PR支持tcp_user_timeout。
是的，我们这边遇到过这类问题——NTP误差或人为操作等原因导致的时钟跳变会导致触发时机提前或者延后。 对于进程内的计时，用单调时钟更合理，避免时钟跳变的影响。 之前尝试改了一下定时器的实现，运行是没有问题的。目前考虑：框架内部计时统一使用单调时钟。对于已经对外的墙上时钟接口，内部转成单调时钟。另外提供对应的单调时钟接口。但是pthread锁相关接口用的是墙上时间。 @wwbmmm 有什么建议吗？
支持设置时钟类型，这样更灵活，但是TimerThread得同时支持两种时钟模式，复杂度可能会变大。
是的，RPC用单调时钟就可以满足超时的需求了。
Use domain name with lb, like `channel.Init("http://baidu.com", "rr", &opts)`. DomainNamingService will periodically query DNS to get the latest IP.
我理解这是为一种退避策略吧
嗯嗯，我说的退避策略也是指IsolationDuration