[Bug] In Dubbo 3, under a multi-registry, shared configuration center setup, when a provider exposes and registers an interface invoker, the interface-level dynamic configurations experience a delay in taking effect

[renyuweighub]

Pre-check

• [x] I am sure that all the content I provide is in English.

Search before asking

• [x] I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Dubbo Java 3.2.11，jdk 1.8，mac os 14.2

Steps to reproduce this issue

1.First, define and deploy the provider of the RPC interface com.demo.framework.dubbo.demo.api.UdubboDemoService

2.Use the FORCE_INTERFACE invocation strategy

dubbo.application.migration.step=FORCE_INTERFACE

3.Start the subscriber application to invoke the provider, and observe the weight config value

4.Then modify the subscriber’s interface-level dynamic configuration for weight

5.Again modify the subscriber’s interface-level dynamic configuration for weight

6.Observe whether the dynamic configuration's weight takes effect for the second time to 81

What you expected to happen

I changed the weight for the second time to 81, but the observed weight value used during the actual invocation was 80, failing to match the latest configuration.

Anything else

My preliminary investigation suggests the issue may be related to using two registries to publish the service, where both registries share a single configuration center and are used for both interface-level and application-level exposure and registration.

Specifically, there seems to be an overwrite issue in the serviceConfigurationListeners interface dynamic configuration listener cache within the RegistryProtocol class.

For the same interface, two ServiceConfigurationListener instances are cached. Since serviceConfigurationListeners is a Map structure, only the last one is retained, and the previous one is overwritten.

However, the first added listener is the one that receives and downloads the latest configuration. This leads to an inconsistency in the following line of code:

newUrl = getConfiguredInvokerUrl(serviceConfigurationListeners.get(originUrl.getServiceKey()).getConfigurators(), newUrl)

Here, the system retrieves the second added listener, which has not received the latest configuration update, resulting in the use of the old configuration, inconsistent with the configuration downloaded by the currently active listener.

Are you willing to submit a pull request to fix on your own?

• [x] Yes I am willing to submit a pull request on my own!

Code of Conduct

• [x] I agree to follow this project's Code of Conduct