Fix thread pool configuration is invalid #11543

sadlay · 2023-02-13T08:02:19Z

What is the purpose of the change

why:
Initiating RPC in the life cycle initialization phase of Spring Bean, that is, before ServiceBean#afterPropertiesSet, because configManager does not have any serviceConfig, and without publishing any provider, the DefaultApplicationDeployer#exportMetadataService() method is first triggered, resulting in org.apache.dubbo.metadata The .MetadataService metadata interface is exported first, and finally the url is passed and fixed in the ChannelHandler. After the service starts to receive the request, when obtaining the ExecutorService, the thread pool of the MetadataService is obtained through the url, not the thread pool configured by parameters such as dubbo.protocol.threads.

how:
When the getExecutor(URL url) method obtains the thread pool, if it is the provider side and has a user-defined interface, the service thread pool will be used first to avoid using its own thread when the registered URL is org.apache.dubbo.metadata.MetadataService pool.

Brief changelog

Verifying this change

Checklist

Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
Each commit in the pull request should have a meaningful subject line and body.
Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
Add some description to dubbo-website project if you are requesting to add a feature.
GitHub Actions works fine on your own branch.
If this contribution is large, please follow the Software Donation Guide.

AlbumenJ

LGTM. Fix for 3.1.x, and. should be fixed by executor isolation in 3.2.x

AlbumenJ · 2023-02-20T08:14:36Z

...mmon/src/main/java/org/apache/dubbo/common/threadpool/manager/DefaultExecutorRepository.java

+    private Map<Integer, ExecutorService> getExecutors(URL url) {
+        Map<Integer, ExecutorService> executors;
+        // if it's on the provider side and has user-defined services, use biz service executor first, avoid using internal executor
+        if (PROVIDER_SIDE.equalsIgnoreCase(url.getParameter(SIDE_KEY))
+            && data.containsKey(EXECUTOR_SERVICE_COMPONENT_KEY)) {
+            executors = data.get(EXECUTOR_SERVICE_COMPONENT_KEY);
+        } else {
+            executors = data.get(getExecutorKey(url));
+        }
+        return executors;
+    }
+


I have a question that why ServiceDescriptor serviceDescriptor = applicationModel.getInternalModule().getServiceRepository().lookupService(url.getServiceInterface()); not work?

Because url.getServiceInterface() always returns MetadataService, when the MetadataService is first loaded.

The PortUnificationExchanger#reset method will return a new url instead of updating, so the Map in AbstractPortUnificationServer#supportedUrls will not be changed.

in NettyPortUnificationServerHandler#decode , localUrl is set by the value in urlMapper, not the updated url

So the url is still MetadataService.

AlbumenJ · 2023-02-22T12:23:51Z

Change getExecutorKey to:

    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;
    }