wisdomrenyuwei opened a new issue, #15783:
URL: https://github.com/apache/dubbo/issues/15783

   ### 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.ucarinc.framework.dubbo.demo.api.UdubboDemoService
   <br class="Apple-interchange-newline">
   
   <img width="338" height="602" alt="Image" 
src="https://github.com/user-attachments/assets/da3a6e46-524f-4c6d-93c4-333a7ec9d336";
 />
   
   2.Then modify the subscriber’s interface-level dynamic configuration for 
timeout and retries
   
   <img width="961" height="698" alt="Image" 
src="https://github.com/user-attachments/assets/565bf0e6-2b7f-415a-b021-cb2a1c91853c";
 />
   
   3.Use the FORCE_INTERFACE invocation strategy
   
    dubbo.application.migration.step=FORCE_INTERFACE
   
   4.Start the subscriber application to invoke the provider, and observe the 
actual timeout and retry configuration values used during the invocation
   
   <img width="1358" height="478" alt="Image" 
src="https://github.com/user-attachments/assets/1e440856-8cb4-4ea5-9464-9762be5f81eb";
 />
   
   <img width="1290" height="143" alt="Image" 
src="https://github.com/user-attachments/assets/a18b93ff-83bb-4e3d-8012-32497524a398";
 />
   
   ### What you expected to happen
   
   I expect the timeout and retry configuration values to match the 
interface-level dynamic configuration, where the timeout should be 3001 and the 
retry count should be 4. However, the actual behavior does not meet this 
expectation. In principle, the caller’s interface-level dynamic configuration 
should have the highest priority, but after restarting the application, the 
configuration does not take effect. This issue is consistently reproducible. 
The configuration only becomes effective if I modify the interface-level 
dynamic configuration again after the application starts.
   
   ### Anything else
   
   This issue of configuration loss upon restart only occurs at the 
interface-level call. For the consuming application (caller), it is 100% 
reproducible
   
   The root cause identified through self-investigation is that the 
configuration becomes invalid because the referenceConfigurationListener is 
null/empty after starting the subscriber application
   
   <img width="1187" height="482" alt="Image" 
src="https://github.com/user-attachments/assets/3b019f81-b840-4bcc-9287-292ecf2e4cb5";
 />
   
   
   <img width="1564" height="575" alt="Image" 
src="https://github.com/user-attachments/assets/5b2f4cda-b0db-422b-95d1-db5ad747ffc6";
 />
   
   The investigation into why the referenceConfigurationListener was null 
points to a potential timing issue in the RegistryDirectory class's subscribe 
method: providers are being subscribed to before the 
referenceConfigurationListener is initialized. The problem could be resolved by 
placing the referenceConfigurationListener initialization logic before the call 
to super.subscribe(url)
   
   ### Are you willing to submit a pull request to fix on your own?
   
   - [ ] 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]

Reply via email to