Jane
Jane
client样例中的代码是这样给出的： ` RpcClient rpcClient = new RpcClient(serviceUrl, clientOption, interceptors);` 但实际运行的时候出现了下面的代码在new RpcClient的时候没有走到的情况： `ExtensionLoaderManager.getInstance().loadAllExtensions("UTF-8");` 导致出现java.lang.RuntimeException: protocol not exist, type=1的报错（1对应baidustd协议）
**Describe the bug (描述bug)** 写一个简单的client去压测单机server，获取如下两个指标： client耗时：通过brpc::Controller::latency_us()获取 server耗时：通过bvar中的对应latency bvar获取 之前我们使用的版本是0.9.7，client侧耗时会明显大于server耗时，符合预期 最近升级到了1.5.0版本，client侧耗时基本不变，但是server侧耗时明显高于之前，甚至大于client侧耗时。 因此怀疑server端的耗时在新版本内有问题。 看了下用于计时的ConcurrencyRemover的逻辑并没有明显修改， 这块还有什么别的排查思路吗？Appreciate any help **To Reproduce (复现方法)** 补充细节： client就是简单的client，请求来自rpc dump采集，单线程使用同步接口去重复发请求。 server是我们的生产代码，特点是：会使用bthread做一些并行计算；使用了brpc的session_local_data。 client和server压测，正常负载下均可以复现 **Expected behavior (期望行为)** 在新版本中，client侧耗时不应该小于server耗时，预期会有明显的gap **Versions (各种版本)** OS:...
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** lalb在SelectServer的循环中，如果选到不可用的节点，在一定条件下会继续尝试节点树的右子树： [判断是否可以进入右子树](https://github.com/apache/brpc/blob/master/src/brpc/policy/locality_aware_load_balancer.cpp#L334) 例如某一时刻节点树只有两个节点，0号不可用1号可用。 按照现在的逻辑如果第一次选中了0，那么这次选择会失败，因为0没有可用的右子树，但是节点树里确实有可用的1号节点。如果连续两次（n=2）一开始选到0，那这一次lb会失败。 在有节点探活失败的情况下可能发生，虽然概率不大，但运气不好每次都选中不可用节点的概率确实存在，尤其是在下游节点不多的情况下。 **Describe the solution you'd like (描述你期望的解决方法)** 在单次Select循环中，如果节点不可用即[判断是否可以进入右子树](https://github.com/apache/brpc/blob/master/src/brpc/policy/locality_aware_load_balancer.cpp#L334)为false， 那么尝试进入左子树作为兜底，例如： `else { dice = butil::fast_rand_less_than(left); index = index...