Triple协议 consumer端线程池线程数依赖于provider端配置

[XingyuFu]

• I have searched the issues of this repository and believe that this is not a duplicate.

Environment

• Dubbo version: 3.2.7
• Java version: 8

Steps to reproduce this issue

构造一个Consumer，一个Provider端

1. Provider端只提供triple协议，线程池大小为1200。
   
   具体的接口级注册中心的信息如下：side=provider，threads=1200
   
2. 重新部署下Consumer，进行多次调用
3. 在org.apache.dubbo.rpc.protocol.tri.TripleInvoker 类中打断点，debug查看streamExecutor，可以看到核心线程数为1200.
   

追踪代码的话，可以从org.apache.dubbo.common.threadpool.manager.DefaultExecutorRepository#createExecutorIfAbsent中看，线程池是根据url创建出来的。

更内部的线程池参数，org.apache.dubbo.common.threadpool.support.fixed.FixedThreadPool，是从url的threads参数获取的。

这就引申出一个问题：Consumer端的这个线程池，核心线程数是依赖于Provider端url配置的。
Provider端面临的场景和Consumer端可能不同，机器配置、数量上都可能不相同。Provider对自己这边配置的合理线程数，对Consumer这一端可能就不合理了。
我们这边使用的时候，可能会存在OOM风险。

[EarthChen]

Would you like to take a PR to fix it?

[finefuture]

@EarthChen @XingyuFu Fixed in pr #13294 #13178

[finefuture]

Fixed in #13304

[bert82503]

Triple协议，能否彻底地解决dubbo协议中的"Thread pool is EXHAUSTED!"问题？
Triple协议，线程池参数，还需要和dubbo协议这样，怎么配置合理？官方有推荐的最佳实践吗？
我的理解，triple协议是基于HTTP/2协议，使用多路复用和事件监听机制，不需要通过线程数量来抗请求数吧。

[AlbumenJ]

Triple协议，能否彻底地解决dubbo协议中的"Thread pool is EXHAUSTED!"问题？ Triple协议，线程池参数，还需要和dubbo协议这样，怎么配置合理？官方有推荐的最佳实践吗？ 我得理解，triple协议是基于HTTP/2协议，使用多路复用和事件监听机制，不需要通过线程数量来抗请求数吧。

HTTP/2 层面的反压对于上层业务的效果本身是不好的，对于实时业务的请求我们更期望的是“尽力”处理，所以最佳的方案是走协程，在 3.3 的 beta 中我们已经支持配置 loom 协程作为线程池

[bert82503]

Triple协议，能否彻底地解决dubbo协议中的"Thread pool is EXHAUSTED!"问题？ Triple协议，线程池参数，还需要和dubbo协议这样，怎么配置合理？官方有推荐的最佳实践吗？ 我的理解，triple协议是基于HTTP/2协议，使用多路复用和事件监听机制，不需要通过线程数量来抗请求数吧。

HTTP/2 层面的反压对于上层业务的效果本身是不好的，对于实时业务的请求我们更期望的是“尽力”处理。所以，最佳的方案是走协程，在 3.3 的 beta 中我们已经支持配置 loom 协程作为线程池。

dubbo-3.3引入Java Loom协程，非常棒的特性。请问什么时候发布正式版本？

Dubbo 3 之 Triple 流控反压原理解析
https://cn.dubbo.apache.org/zh-cn/blog/2022/12/28/dubbo-3-%e4%b9%8b-triple-%e6%b5%81%e6%8e%a7%e5%8f%8d%e5%8e%8b%e5%8e%9f%e7%90%86%e8%a7%a3%e6%9e%90/

2018年，《Reactive 架构升级实践——淘宝全站业务的全异步流式架构升级》，实际真实效果咋样？