brpc
brpc copied to clipboard
apache
brpc is an Industrial-grade RPC framework using C++ Language, which is often used in high performance system such as Search, Storage, Machine learning, Advertisement, Recommendation etc. "brpc" means...
 在使用过程中，观察server侧的火焰图，此时brpc_worker thread的cpu基本打满。发现futex_wake、futex_wait占用的时间占比比较高，竞争锁成为了瓶颈。怀疑可能是由于调度不均衡，某些worker中的task较多，而一些worker的task较少，当这些task消费完之后每次都会调用wait，然后又快速被signal唤醒。同时也存在parking_lot中没有wait的线程但仍然在signal的场景。 这方面是否存在一些优化点，比如： 1. signal时判断是否存在wait状态的线程； 2. wait之前先尝试steal_task n 次，如果都失败再wait挂起线程；或者wait时设置timeout时间而不是每次都是永久wait，只能被signal主动唤醒。
**Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)** bRPC已支持现代化的bazel编译框架，但对UT的编译不够完善，缺少维护，这对于使用bazel的开发者不友好。 如test目录下BUILD.bazel涵盖的UT用例不全，只编译了bvar, bthread, butil等模块，且这些模块中一些UT源文件还被excluded了，至于brpc开头的ut源文件都没有编译。 我尝试了编译完整的UT，确实存在很多编译报错（如echo.pb.h找不到），但通过努力发现大多数问题都能修改解决。 I will try to fix this. **Describe the solution you'd like (描述你期望的解决方法)** **Describe alternatives you've considered...
**Is your feature request related to a problem?** brpc通过grpc协议调用dubbo服务，因为首个包体比较大且和setting一起发，导致dubbo侧没法及时更新窗口大小而抛异常，进而把流连接也关闭了，和后面这几个issue是类似的，只是这几个issue提供的解决方案在我们这个场景行不通，需要改netty源码才行。这个问题的本质还是brpc实现的grpc协议没有标准grpc协议的握手环节，有些设置没更新就发数据包体。想请教一下咱们是否会支持下grpc协议在TCP连接建立后的握手环节呐 **Describe the solution you'd like** **Describe alternatives you've considered** **Additional context/screenshots**
您好，当前由于工作需要，想要使用h2协议来支持rdma，我这样直接改是不是就可以，测试未发现什么问题 bool SupportedByRdma(std::string protocol) { if ((protocol.compare("baidu_std") == 0) || (protocol.compare("h2") == 0)) { // Since rdma is used for high performance scenario, // we consider baidu_std for the only...
**Describe the bug (描述bug)** 使用BRPC框架的进程，长期运行(一个月)，可以观察到内存持续上涨，如下图：  追踪内存泄漏位置如下  **To Reproduce (复现方法)** 单进程2k左右qps， 消息请求平均大小150KB **Expected behavior (期望行为)** 期望内存不会持续上涨 **Versions (各种版本)** OS: Linux 5.15.0-125.006 #125~20.04.3 SMP Fri May 24 11:59:50 +08 2024...
### What problem does this PR solve? Issue Number: Problem Summary: 以下引起E112错误之后无法自行恢复的几种场景： 1. 网络抖动后遗症，一直出现E112无法自行恢复 配置dns访问外网，dns只解析出一个ip，然后网络抖动过程中出现少量连接失败，返回错误码为ECONNREFUSED或ENETUNREACH或EHOSTUNREACH或EINVAL，满足does_error_affect_main_socket从而触发main socket SetFailed。 但是正常来说，SetFailed之后过100ms就开始健康检查，每3秒重试一次。所以按理当网格抖动恢复后，最长3秒后，就不应该再出现E112了。但是实际上仍有E112持续出现，如果重启进程，则不会再出现。 2. 以single server模式初始化channel，第一次连接失败之后socket被SetFailed，后面重试就都选不出服务了。 3. 出现一个ETIMEOUT之后，就一直出现EHOSTDOWN，没有恢复。 ### What is changed and the side...
### What problem does this PR solve? Issue Number: resolve #1251 Problem Summary: The read_command_name function previously used /proc/self/stat to retrieve command names, which could lead to incorrect handling of...
**Describe the bug** brpc在 arm64环境 内存 快速增长 后oom, 使用 valgrind会显示 很多内存 泄漏, 不确定 是 哪儿 的 问题， 另外就是 如果 加上 tcmalloc后， 就不会一直内存增长 **To Reproduce** **Expected behavior** **Versions** OS: Linux xxx...
hi ，我目前想用brpc做一些http相关的工作，基本的逻辑是client发送request给server，server那边会在一段时间内产生多个responses，所以client应该要持续的流式接收这些responses。目前我的client只能接收到最终的batch在一起resps，而不是每次streaming的收到返回值。帮忙看下这一块是否有解决办法呢，感谢🙏. 目前server的写resp的逻辑大概如下: ``` class ServerStreamData{ public: ServerStreamData(brpc::Controller* controller, ::google::protobuf::Closure* done) : controller_(controller), done_(done) { pa_ = controller_->CreateProgressiveAttachment(); controller_->http_response().set_content_type("text/event-stream"); controller_->http_response().set_status_code(200); controller_->http_response().SetHeader("Connection", "keep-alive"); controller_->http_response().SetHeader("Cache-Control", "no-cache"); // stream模式下，先将done执行 done_->Run(); } // server每次产生一个data就会调用一次这个write函数...
