Open luoning810 opened 5 months ago
@chickenlj PTAL
currently, when update dynamic configuration in dubbo-admin, the key is only serviceName, no group and version to be registered in registry center. so it can't be matched. temporarily, You can manually add group and version to the dynamic configuration to solve this problem. just like this:
configVersion: v2.7
enabled: true
configs:
- side: consumer
addresses:
- 0.0.0.0
parameters:
timeout: 2900
group: test
version: 1.0.0
I think it is best to modify the registration behavior of dubbo-admin.
@laywin From my understanding, it's an issue of dubbo-admin. dubbo-admin registered the rule with a wrong id or match key which caused the Dubbo SDK cannot recognize the rule, so it never gets parsed and worked on SDK.
We realized the current dubbo-admin implementation has some issues especially with traffic management features. So we are working on building a brand new dubbo admin with Golang language. Aside from visualized console, we expect it to also support deploying Dubbo on Kubernetes by leveraging the Kubernetes Service concept.
The incubating repo is here https://github.com/apache/dubbo-kubernetes
@laywin From my understanding, it's an issue of dubbo-admin. dubbo-admin registered the rule with a wrong id or match key which caused the Dubbo SDK cannot recognize the rule, so it never gets parsed and worked on SDK.
We realized the current dubbo-admin implementation has some issues especially with traffic management features. So we are working on building a brand new dubbo admin with Golang language. Aside from visualized console, we expect it to also support deploying Dubbo on Kubernetes by leveraging the Kubernetes Service concept.
The incubating repo is here https://github.com/apache/dubbo-kubernetes
sounds great!
Thank you very much for the response above. We are currently validating the upgrade from Dubbo 2.7 to Dubbo 3.2. DubboAdmin is indeed using a version adapted to 2.7, but I understand that the differences in interface-level dynamic configuration between the old and new versions mainly lie in whether the key includes the group and version. Even if we remove the group and version from the key, Dubbo still does not work properly.
I tried to analyze the issue and believe the problem occurs in the following areas:
When referenceConfigurationListener.getConfigurators() is not empty, the overriddenURL may need to add group and version parameters so that AbstractConfigurator#isV27ConditionMatchOrUnset(overriddenURL) returns the correct result when comparing the configServiceKey.
Currently, line 195 always returns false because the url is the overriddenURL mentioned above, which only includes the application name and does not contain the group and version.
This problem is that dubbo-admin don't registry group and version with key to the registration center. you will see sdk has the operation to parse group and version in ConfigParser#appendService
private static String appendService(String serviceKey) {
StringBuilder sb = new StringBuilder();
if (StringUtils.isEmpty(serviceKey)) {
throw new IllegalStateException("service field in configuration is null.");
}
String interfaceName = serviceKey;
int i = interfaceName.indexOf('/');
if (i > 0) {
sb.append("group=");
sb.append(interfaceName, 0, i);
sb.append('&');
interfaceName = interfaceName.substring(i + 1);
}
int j = interfaceName.indexOf(':');
if (j > 0) {
sb.append("version=");
sb.append(interfaceName.substring(j + 1));
sb.append('&');
interfaceName = interfaceName.substring(0, j);
}
sb.insert(0, interfaceName + "?");
return sb.toString();
}
but serviceKey don't have group and version. you can also config them in dubbo admin 's parameters
parameters:
timeout: 2900
group: test
version: 1.0.0
I agree with your point. The configurator URL of the override protocol can include the group and version added through DubboAdmin. In the screenshot below, the group and version added by DubboAdmin are in the configuratorUrl, which I believe is as expected. However, the url variable does not contain the group and version, which I think is unexpected. This inconsistency leads to different results when calling getServiceKey with configuratorUrl compared to url.
I agree with your point. The configurator URL of the override protocol can include the group and version added through DubboAdmin. In the screenshot below, the group and version added by DubboAdmin are in the configuratorUrl, which I believe is as expected. However, the url variable does not contain the group and version, which I think is unexpected. This inconsistency leads to different results when calling getServiceKey with configuratorUrl compared to url.
Thanks for the detailed explanation, it's indeed an matching issue, I will fix it now.
By the way, if you are using Dubbo 3.2.x, the following configuration rule is recommended:
configVersion: v3.0
scope: service
key: org.apache.dubbo.samples.UserService
configs:
- match:
application:
oneof:
- exact: shop-frontend
side: consumer
parameters:
retries: '4'
As explained here https://cn.dubbo.apache.org/zh-cn/overview/core-features/traffic/configuration-rule/
Thank you for your response and suggestions.
Please close this pr as complete @AlbumenJ
Pre-check
Search before asking
Apache Dubbo Component
Java SDK (apache/dubbo)
Dubbo Version
Dubbo java 3.2.11,oracle jdk 1.8
Steps to reproduce this issue
step 1 add service mode dynamic config
step 2 ReferenceConfigurationListener#notifyOverrides
step3 RegistryDirectory#refreshOverrideAndInvoker() -> refreshInvoker()
step4 mergeUrl
step5 overrideWithReferenceConfigurators
step6 service configurator rule mismatch
What you expected to happen
isV27ConditionMatchOrUnset return true when application and service is matched
Anything else
No response
Are you willing to submit a pull request to fix on your own?
Code of Conduct