线程池配置失效

[sadlay]

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

在通过 dubbo.protocol.threads 配置线程池数量后（包括其他线程池参数），会在某些情况下失效。

Environment

• Dubbo version: 3.1.1
• Operating System version: MacOS，Linux，Windows全平台
• Java version: 1.8

Steps to reproduce this issue

1. 服务调用链路 A -> B -> C

2. 所有服务配置线程池参数：

   dubbo.protocol.threadpool=fixed
   dubbo.protocol.threads=720
   dubbo.protocol.corethreads=720

3. 在服务 B 中编写一个Spring Bean，实现 InitializingBean （或 BeanNameAware 等）接口，在实现方法中调用服务 C 的接口，用于初始化一些数据

4. 所有应用启动后，服务 A 调用服务 B 接口，观察服务B 的线程池

Expected Behavior

服务 B 的线程池

• 类型： fixed
• 数量：720
• 核心：720

Actual Behavior

服务 B 的线程池

• 类型： cached
• 数量：100
• 核心：2

Analysis

例如在 Spring Bean 的生命周期初始化阶段发起 RPC 远程调用，也就是 ServiceBean#afterPropertiesSet 之前，由于configManager 不存在任何 serviceConfig，在未发布任何 provider 情况下，首先触发了 DefaultApplicationDeployer#exportMetadataService() 方法，导致org.apache.dubbo.metadata.MetadataService 元数据接口被第一个 export ，之后走到DubboProtocol#openServer方法，此时serverMap 为空，所以创建进入 createServer方法

之后将 MetadataService 的 URL 注册到org.apache.dubbo.remoting.transport.AbstractServer#url中，

最终将该 url 传递到了 ChannelHandler 中。

而在服务启动，接收请求后，获取 ExecutorService 时，由于是通过URL获取，所以取到 MetadataService 的线程池，而非 dubbo.protocol.threads 等参数配置的线程池

[icodening]

看了下确实有这个问题，当启动时没有发布任何服务，而在运行时动态发布就可以复现了

[sadlay]

最新发现，除了线程池配置，payload配置也失效。

[AlbumenJ]

这个问题是不是通过 3.2 的线程池隔离方案来解好些

[AlbumenJ]

https://cn.dubbo.apache.org/zh-cn/docs3-v2/java-sdk/advanced-features-and-usage/service/isolation-executor/

改成默认就是 isolation 的配置，如果没有指定独立线程池就使用协议默认的，如果指定了就使用指定的。这样 internal 服务就可以直接使用特定的线程池去隔离

[sadlay]

最新发现，除了线程池配置，payload配置也失效。

实测3.1.6版本已解决，但是线程池配置问题依旧存在。

[sadlay]

https://cn.dubbo.apache.org/zh-cn/docs3-v2/java-sdk/advanced-features-and-usage/service/isolation-executor/

改成默认就是 isolation 的配置，如果没有指定独立线程池就使用协议默认的，如果指定了就使用指定的。这样 internal 服务就可以直接使用特定的线程池去隔离

这个配置只有 3.2 版本支持吗？看到还没有正式的发行版本。我们服务已经部署到生产上了，对稳定性要求较高。
目前的解决方案为改为接口级注册，同时添加 dubbo.application.register-consumer=false 配置，取消 MetadataService 接口发布来解决此问题的。
请问该方案是否有隐藏问题，或者是否有其他的更好的办法？

[AlbumenJ]

https://cn.dubbo.apache.org/zh-cn/docs3-v2/java-sdk/advanced-features-and-usage/service/isolation-executor/
改成默认就是 isolation 的配置，如果没有指定独立线程池就使用协议默认的，如果指定了就使用指定的。这样 internal 服务就可以直接使用特定的线程池去隔离

这个配置只有 3.2 版本支持吗？看到还没有正式的发行版本。我们服务已经部署到生产上了，对稳定性要求较高。 目前的解决方案为改为接口级注册，同时添加 dubbo.application.register-consumer=false 配置，取消 MetadataService 接口发布来解决此问题的。 请问该方案是否有隐藏问题，或者是否有其他的更好的办法？

接口级的应该也还好，或者可以配置下 metadata-report 为 remote

[wdinghua]

这个问题是不是通过 3.2 的线程池隔离方案来解好些

能否在3.0和3.1版本修复一下这个问题，补充一些信息：

1. provider 在受理 consumer 的调用请求时，获取 ExecutorService 时，使用的是构造 ChannelHandler 时传入的 url ，该url是 StandardMetadataServiceURLBuilder 生成的，而StandardMetadataServiceURLBuilder生成url时定死了thread pool的相关参数

代码截图

调用证明：
provider 在受理 processAudioUpdate4Cache 调用时，使用 MessageOnlyChannelHandler 受理请求，MessageOnlyChannelHandler 初始化的 url 是 StandardMetadataServiceURLBuilder 生成的（url中参数为：threadpool=cached&threads=100）

[arthas@7364]$ tt -i 1226
INDEX 1226
GMT-CREATE 2023-02-20 15:52:21
COST(ms) 0.014597
OBJECT 0x30779ea6
CLASS org.apache.dubbo.remoting.transport.dispatcher.message.MessageOnlyChannelHandler
METHOD received
IS-RETURN true
IS-EXCEPTION false
PARAMETERS[0] @NettyChannel[
logger=@FailsafeErrorTypeAwareLogger[org.apache.dubbo.common.logger.support.FailsafeErrorTypeAwareLogger@374e1a30],
CHANNEL_MAP=@ConcurrentHashMap[isEmpty=false;size=12],
channel=@NioSocketChannel[[id: 0x1679b9a9, L:/xx.xx.xx.152:9034 - R:/xx.xx.xx.183:25492]],
attributes=@ConcurrentHashMap[isEmpty=false;size=3],
active=@AtomicBoolean[true],
handler=@NettyServer[org.apache.dubbo.remoting.transport.netty4.NettyServer@2c827a42],
url=@ServiceConfigURL[dubbo://xx.xx.xx.152:9034/org.apache.dubbo.metadata.MetadataService?accepts=1500&accesslog=false&anyhost=true&application=xxxxxx&background=false&bind.ip=xx.xx.xx.1
52&bind.port=9034&channel.readonly.sent=true&client=netty4&codec=dubbo&connections=1&corethreads=2&delay=0&deprecated=false&dispatcher=message&dubbo=2.0.2&dynamic=true&executes=100&generic=false&getAndList
enInstanceMetadata.1.callback=true&getAndListenInstanceMetadata.return=true&getAndListenInstanceMetadata.sent=true&group=xxxxxx&heartbeat=60000&interface=org.apache.dubbo.metadata.MetadataSe
rvice&methods=exportInstanceMetadata,getAndListenInstanceMetadata,getExportedServiceURLs,getExportedURLs,getExportedURLs,getExportedURLs,getExportedURLs,getExportedURLs,getInstanceMetadataChangedListenerMa
p,getMetadataInfo,getMetadataInfos,getMetadataURL,getServiceDefinition,getServiceDefinition,getSubscribedURLs,isMetadataService,serviceName,toSortedStrings,toSortedStrings,version&pid=7364&qos.accept.forei
gn.ip=false&qos.enable=true&qos.port=20034&register=false&release=3.1.6&revision=3.1.6&rootPath=/dubbo-build&server=netty4&side=provider&threadname=protocol_thread-xx.xx.xx.152:9034&threadpool=cached&threa
ds=100&timestamp=1676875328236&transporter=netty4&version=1.0.0],
closing=@boolean[false],
closed=@boolean[false],
]
PARAMETERS[1] @request[
INVOKE_ID=@AtomicLong[2219],
mId=@long[3153229],
mVersion=@string[2.0.2],
mTwoWay=@boolean[true],
mEvent=@boolean[false],
mBroken=@boolean[false],
mData=@DecodeableRpcInvocation[RpcInvocation [methodName=processAudioUpdate4Cache, parameterTypes=[class java.lang.String, class java.lang.String, class java.lang.String]]],
]
RETURN-OBJ null
Affect(row-cnt:1) cost in 1 ms.

[arthas@7364]$ tt -i 1226 -w target
@MessageOnlyChannelHandler[
logger=@FailsafeErrorTypeAwareLogger[org.apache.dubbo.common.logger.support.FailsafeErrorTypeAwareLogger@1047a48],
handler=@DecodeHandler[org.apache.dubbo.remoting.transport.DecodeHandler@50e9124f],
url=@ServiceConfigURL[dubbo://xx.xx.xx.152:9034/org.apache.dubbo.metadata.MetadataService?accepts=1500&accesslog=false&anyhost=true&application=xxxxxx&background=false&bind.ip=xx.xx.xx.152&bind.port=9034&channel.readonly.sent=true&client=netty4&codec=dubbo&connections=1&corethreads=2&delay=0&deprecated=false&dispatcher=message&dubbo=2.0.2&dynamic=true&executes=100&generic=false&getAndListenInstanceMetadata.1.callback=true&getAndListenInstanceMetadata.return=true&getAndListenInstanceMetadata.sent=true&group=xxxxxx&heartbeat=60000&interface=org.apache.dubbo.metadata.MetadataService&methods=exportInstanceMetadata,getAndListenInstanceMetadata,getExportedServiceURLs,getExportedURLs,getExportedURLs,getExportedURLs,getExportedURLs,getExportedURLs,getInstanceMetadataChangedListenerMap,getMetadataInfo,getMetadataInfos,getMetadataURL,getServiceDefinition,getServiceDefinition,getSubscribedURLs,isMetadataService,serviceName,toSortedStrings,toSortedStrings,version&pid=7364&qos.accept.foreign.ip=false&qos.enable=true&qos.port=20034&register=false&release=3.1.6&revision=3.1.6&rootPath=/dubbo-build&server=netty4&side=provider&threadname=protocol_thread&threadpool=cached&threads=100&timestamp=1676875328236&transporter=netty4&version=1.0.0],
]
Affect(row-cnt:1) cost in 1 ms.

[AlbumenJ]

这样的话是不是可以把改成

    private String getExecutorKey(URL url) {
        if (CONSUMER_SIDE.equalsIgnoreCase(url.getParameter(SIDE_KEY))) {
            return CONSUMER_SHARED_EXECUTOR_SERVICE_COMPONENT_KEY;
        }
        return EXECUTOR_SERVICE_COMPONENT_KEY;
    }

[AlbumenJ]

Will be fixed in #11652

[ZhaoGZzzzzzzz]

Dubbo version 3.1.8，现在的问题似乎反过来了：当dubbo.application.metadata-type=local，并且org.apache.dubbo.metadata.MetadataService 最后一个export时，org.apache.dubbo.common.threadpool.manager.DefaultExecutorRepository#getExecutorKey(URL) 获取到provider的线程池，并使用threadpool=cached&threads=100&corethreads=2覆盖corePoolSize、maximumPoolSize

[AlbumenJ]

@aamingaa PTAL

[ZhaoGZzzzzzzz]

是否应去掉 org.apache.dubbo.config.metadata.ConfigurableMetadataServiceExporter#buildServiceConfig 中的 threadParams 参数来保持 MetadataService 与 provider 线程池配置的一致性？

[why168]

目前v3.1.8有问题，升级v3.1.10得到解决。