dubbo_3.1.10因refer MetadataService导致本服务线程池被覆盖，线程数设置失败

[xm101]

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

Environment

• Dubbo version: 3.1.10
• Operating System version: ALL
• Java version: 1.8.0

Steps to reproduce this issue

1. 我们2个微服务A,B使用了Dubbo 3.1.10，metadata-type都为默认的local，metadataServicePort未设置，dubbo端口一样
2. 服务B调用服务A，同时服务B对外提供服务
3. 服务B设置服务线程threads为200

Expected Behavior

预期服务B的服务线程池为FixedThreadPool线程数为200

Actual Behavior

实际服务B的服务线程池为CachedThreadPool

bug调试

org.apache.dubbo.registry.client.metadata.StandardMetadataServiceURLBuilder#getMetadataServiceURLsParams
取到的

存在key:"side":"provider"

org.apache.dubbo.registry.client.metadata.StandardMetadataServiceURLBuilder#generateWithMetadata

这里consumer被覆盖为provider

org.apache.dubbo.common.threadpool.manager.DefaultExecutorRepository#getExecutorKey
导致这里的executorKey错误

org.apache.dubbo.common.threadpool.manager.DefaultExecutorRepository#createExecutorIfAbsent
导致这里覆盖了服务端的线程池

[stonelion]

遇到了相同问题，可解决。

[stonelion]

@xm101 generateUrlWithoutMetadata 也需要修改一下。

[xm101]

@xm101 generateUrlWithoutMetadata 也需要修改一下。

generateUrlWithoutMetadata方法在注册中心获取不到meta相关信息时调用，就我遇到的这个问题而言，因为这里没有来自注册中心的属性，就不存在覆盖问题

[AlbumenJ]

The thread pool problem of MetadataService has been fixed in version 3.2

[AlbumenJ]

Already fixed in #11936

[xm101]

Already fixed in #11936

与#11936 应该不是同个问题，11936是本服务的MetadataService线程池覆盖了业务接口线程池，而这个issues的问题是，业务接口线程池被调用的其他服务暴露出来的MetadataService生成的客户端线程池所覆盖
3.2可能线程池隔离解决了这问题，但是不少像我们一样仍使用JDK8的公司公司需要继续使用3.1.X，希望这个版本也能解决。

[AlbumenJ]

Already fixed in #11936

与#11936 应该不是同个问题，11936是本服务的MetadataService线程池覆盖了业务接口线程池，而这个issues的问题是，业务接口线程池被调用的其他服务暴露出来的MetadataService生成的客户端线程池所覆盖 3.2可能线程池隔离解决了这问题，但是不少像我们一样仍使用JDK8的公司公司需要继续使用3.1.X，希望这个版本也能解决。

1. [3.1] Fix #11524 (#11524) #11936 删除了 MetadataService 主动配置线程池的代码
2. 3.2.x 不强制依赖高版本 JDK，目前 Dubbo 3.2.x 包括未来的 3.3.x 都是支持 jdk8 的

[xm101]

Already fixed in #11936

与#11936 应该不是同个问题，11936是本服务的MetadataService线程池覆盖了业务接口线程池，而这个issues的问题是，业务接口线程池被调用的其他服务暴露出来的MetadataService生成的客户端线程池所覆盖 3.2可能线程池隔离解决了这问题，但是不少像我们一样仍使用JDK8的公司公司需要继续使用3.1.X，希望这个版本也能解决。

1. [3.1] Fix #11524 (#11524) #11936 删除了 MetadataService 主动配置线程池的代码
2. 3.2.x 不强制依赖高版本 JDK，目前 Dubbo 3.2.x 包括未来的 3.3.x 都是支持 jdk8 的

或者这么说吧，我们使用的是3.1.10，已经包含了11524 ConfigurableMetadataServiceExporter这个最新代码，那个问题我也遇到了，所以从3.1.9升级到了3.1.10，但是仍然遇到了这个新问题，上面是一步步调试和排查的结果，PR不小心点了close

[AlbumenJ]

Already fixed in #11936

与#11936 应该不是同个问题，11936是本服务的MetadataService线程池覆盖了业务接口线程池，而这个issues的问题是，业务接口线程池被调用的其他服务暴露出来的MetadataService生成的客户端线程池所覆盖 3.2可能线程池隔离解决了这问题，但是不少像我们一样仍使用JDK8的公司公司需要继续使用3.1.X，希望这个版本也能解决。

1. [3.1] Fix #11524 (#11524) #11936 删除了 MetadataService 主动配置线程池的代码
2. 3.2.x 不强制依赖高版本 JDK，目前 Dubbo 3.2.x 包括未来的 3.3.x 都是支持 jdk8 的

或者这么说吧，我们使用的是3.1.10，已经包含了11524 ConfigurableMetadataServiceExporter这个最新代码，那个问题我也遇到了，所以从3.1.9升级到了3.1.10，但是仍然遇到了这个新问题，上面是一步步调试和排查的结果，PR不小心点了close

ok 我大概知道什么问题了，PR 我会重新打开，等测试跑过后合并。不过现在下一个 3.1.x 的版本发布还没有具体的规划时间，只有 3.2.x 会定期（每月）发版