lei he

检查一下是否有Socket[xxx] isolated by circuit breaker 的log，brpc的默认重连方式只需要tcp能够建立连接，有可能熔断之后又恢复了。 另外connections监控页面也可以检查各个连接的健康状况。 连接超时的熔断需要用iptables drop掉对应端口的包，直接sleep是不行的

可以贴一下完整的代码么，我在server端添加`cntl->SetFailed(brpc::EREQUEST, "Fail to parse request");`之后，在client看到的日志是`W0822 11:08:00.715427 748755 client.cpp:90] [E1003][10.227.87.49:8000][E1003]Failed to parse request`，而你贴的日志是Fail to **send** EchoRequest, 比较奇怪。

 我用你描述的代码是能正常熔断的，默认配置下如果server 错误率100%，第151个请求会触发熔断。 这是我用的代码：https://github.com/TousakaRin/brpc/tree/circuit_breaker_test 有一种可能是你的代码比较老，没有这个commit: https://github.com/apache/incubator-brpc/commit/c59aecdded0fbc01cda5b5462ef99c4d084b31ae

可以在client的connection页面看一下错误数量有没有正确记录

> Update: After hacking some brpc code and restart the machine, we downsample the `signal` in bthread, and the performance works better. what hacks did you make？

github id： TousakaRin brpc 贡献 url：https://github.com/apache/incubator-brpc/commits?author=TousakaRin

> Mongo client有专门的支持naming service和load balancer吗？不是用目前brpc已有的支持naming service和load balancer？ mongodb 是支持主从和分片的，我觉得可以做成专用的lb和naming service，这块的细节还没怎么看

In pooled mode, at most one RPC request can exist on each pooled connection, while in single connection mode + baidu_rpc_protocol, one TCP connection request can carry multiple RPC requests....

> 但是大多数的业务场景都是连接池模式的吧, 很少有单连接的场景 No, it depends on your communication protocol. For protocols like http1.x where the server side must process requests on the same TCP connection **in sequence**，using connection pool...

可以打开rpcz，然后在查询时根据lantecy进行过滤超过500ms的请求，一般来说很容易看到。另外可以检查以下代码里是否使用了brpc的timer功能并且在callback里使用了可能阻塞的代码（不管是阻塞bthread还是phtread都可能会导致这个问题）