[Bug] override url with configurator from "service-name.configurators" in interface mode not as expected

[luoning810]

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，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?

• [ ] 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

[AlbumenJ]

@chickenlj PTAL

[laywin]

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.

[chickenlj]

@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]

@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!

[luoning810]

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.

[laywin]

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

[luoning810]

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.

[chickenlj]

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.

[chickenlj]

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/

[luoning810]

Thank you for your response and suggestions.

[wcy666103]

Please close this pr as complete @AlbumenJ