renyuweighub opened a new issue, #15803: URL: https://github.com/apache/dubbo/issues/15803
### 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](https://github.com/apache/dubbo/issues?q=is%3Aissue) 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 <img width="338" height="602" alt="Image" src="https://github.com/user-attachments/assets/7ff94aae-dc32-475d-bff2-cfc83c7e061f"; /> 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 <img width="828" height="390" alt="Image" src="https://github.com/user-attachments/assets/bf6594a6-e802-47dd-9c34-c0ca98097dac"; /> 5.Again modify the subscriber’s interface-level dynamic configuration for weight <img width="826" height="383" alt="Image" src="https://github.com/user-attachments/assets/5badfa7f-0b38-44de-b9e4-7ffeeaecbd7a"; /> 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](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
