[Bug] When registering services programmatically in Dubbo 3.3.x, the instance - level service registration is invalid. #14859

lineng-hao-jie · 2024-11-05T02:53:35Z

Pre-check

I am sure that all the content I provide is in English.

Search before asking

I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

dubbo 3.3.x ，jdk openjdk-21.0.2 ，windows11
nacos server 2.3.0，nacos-client 2.3.0/2.4.3

Steps to reproduce this issue

When upgrading from 3.2.10/3.2.16 to 3.3.x, it was found that instance - level services could not be registered. The specific manifestations are as follows:
1）Dubbo service calls failed and no services were found.
2）There are no corresponding service registration records in the "Service Management - Service List" in the Nacos console.

What you expected to happen

By comparing the startup logs of 3.2.x and 3.3.x, it was found that the 3.3.x version lacks the metadata service registration information. Specifically, the following lines of logs are missing:

2024-11-05 09:13:11,578 INFO [main] [InternalServiceConfigBuilder.java:209] -  [DUBBO] org.apache.dubbo.metadata.MetadataServiceService Port hasn't been set will use default protocol defined in protocols., dubbo version: 3.2.16, current host: 192.168.10.10
2024-11-05 09:13:11,579 INFO [main] [InternalServiceConfigBuilder.java:266] -  [DUBBO] Using dubbo protocol to export org.apache.dubbo.metadata.MetadataService service on port 18185, dubbo version: 3.2.16, current host: 192.168.10.10
2024-11-05 09:13:11,642 INFO [main] [ServiceConfig.java:965] -  [DUBBO] Export dubbo service org.apache.dubbo.metadata.MetadataService to local registry url : injvm://127.0.0.1/org.apache.dubbo.metadata.MetadataService?anyhost=true&application=travel-wuling&application.version=1.0.0&background=false&bind.ip=192.168.10.10&bind.port=18185&delay=0&deprecated=false&dubbo=2.0.2&dynamic=true&environment=product&executor-management-mode=isolation&exporter.listener=injvm&file-cache=true&generic=false&getAndListenInstanceMetadata.1.callback=true&getAndListenInstanceMetadata.return=true&getAndListenInstanceMetadata.sent=true&group=travel-wuling&interface=org.apache.dubbo.metadata.MetadataService&methods=exportInstanceMetadata,getAndListenInstanceMetadata,getExportedServiceURLs,getExportedURLs,getInstanceMetadataChangedListenerMap,getMetadataInfo,getMetadataInfos,getMetadataURL,getServiceDefinition,getSubscribedURLs,isMetadataService,serviceName,toSortedStrings,version&owner=travel-wuling&pid=3536&prefer.serialization=fastjson2,hessian2&qos.enable=false&register=false&register-mode=instance&release=3.2.16&revision=3.2.16&service.filter=-default&side=provider&timestamp=1730769191606&version=1.0.0, dubbo version: 3.2.16, current host: 192.168.10.10
2024-11-05 09:13:11,642 INFO [main] [ServiceConfig.java:923] -  [DUBBO] Export dubbo service org.apache.dubbo.metadata.MetadataService to url dubbo://192.168.10.10:18185/org.apache.dubbo.metadata.MetadataService?anyhost=true&application=travel-wuling&application.version=1.0.0&background=false&bind.ip=192.168.10.10&bind.port=18185&delay=0&deprecated=false&dubbo=2.0.2&dynamic=true&environment=product&executor-management-mode=isolation&file-cache=true&generic=false&getAndListenInstanceMetadata.1.callback=true&getAndListenInstanceMetadata.return=true&getAndListenInstanceMetadata.sent=true&group=travel-wuling&interface=org.apache.dubbo.metadata.MetadataService&methods=exportInstanceMetadata,getAndListenInstanceMetadata,getExportedServiceURLs,getExportedURLs,getInstanceMetadataChangedListenerMap,getMetadataInfo,getMetadataInfos,getMetadataURL,getServiceDefinition,getSubscribedURLs,isMetadataService,serviceName,toSortedStrings,version&owner=travel-wuling&pid=3536&prefer.serialization=fastjson2,hessian2&qos.enable=false&register=false&register-mode=instance&release=3.2.16&revision=3.2.16&service.filter=-default&side=provider&timestamp=1730769191606&version=1.0.0, dubbo version: 3.2.16, current host: 192.168.10.10
2024-11-05 09:13:11,644 INFO [main] [ConfigurableMetadataServiceExporter.java:80] -  [DUBBO] The MetadataService exports urls : [dubbo://192.168.10.10:18185/org.apache.dubbo.metadata.MetadataService?anyhost=true&application=travel-wuling&application.version=1.0.0&background=false&bind.ip=192.168.10.10&bind.port=18185&delay=0&deprecated=false&dubbo=2.0.2&dynamic=true&environment=product&executor-management-mode=isolation&file-cache=true&generic=false&getAndListenInstanceMetadata.1.callback=true&getAndListenInstanceMetadata.return=true&getAndListenInstanceMetadata.sent=true&group=travel-wuling&interface=org.apache.dubbo.metadata.MetadataService&methods=exportInstanceMetadata,getAndListenInstanceMetadata,getExportedServiceURLs,getExportedURLs,getInstanceMetadataChangedListenerMap,getMetadataInfo,getMetadataInfos,getMetadataURL,getServiceDefinition,getSubscribedURLs,isMetadataService,serviceName,toSortedStrings,version&owner=travel-wuling&pid=3536&prefer.serialization=fastjson2,hessian2&qos.enable=false&register=false&register-mode=instance&release=3.2.16&revision=3.2.16&service.filter=-default&side=provider&timestamp=1730769191606&version=1.0.0], dubbo version: 3.2.16, current host: 192.168.10.10

After tracing the code, it was found that the DefaultApplicationDeployer (v3.3.1) was not executed after line 1302, and it returned in the previous judgment. Specifically:

private void doExportMetadataService() {
        if (!isStarting() && !isStarted() && !isCompletion()) {
            return;
        }
        for (DeployListener<ApplicationModel> listener : listeners) {
            ...
        }
    }

It is suspected that the startup in the new version has some scenarios not considered in the marker control. The differences in startup logic between the two versions have not been compared yet. We have encapsulated a layer on top of Dubbo ourselves, and the registration of services is done programmatically, specifically through ServiceConfig.export(). Additionally, I have also tested that as long as a service is configured in the configuration mode, the service registration information is normal, for example:

<dubbo:service interface="com.huntlee.travel.ai.llm.agent.api.DubboBug" id="dubboBugService" ref="dubboBug"/>

That is to say, in the 3.3.x version, when services(instance level) are registered programmatically, there are problems with service registration. Additionally, it has also been tested that if the service registration is configured as an interface - level service, there is no problem either.

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

I agree to follow this project's Code of Conduct

The text was updated successfully, but these errors were encountered:

laywin · 2024-11-06T06:42:21Z

i have tested dubbo 3.3.1, it successed to register app instance programmatically.

ServiceConfig<Greeter> service = new ServiceConfig<>();
		service.setInterface(Greeter.class);
		service.setRef(new GreeterImpl());
		DubboBootstrap.getInstance().getCache().get(App.class);

		RegistryConfig registryConfig = new RegistryConfig("nacos://127.0.0.1:8848");
		registryConfig.setRegisterMode("instance");
		DubboBootstrap bootstrap = DubboBootstrap.getInstance();
		bootstrap.application(new ApplicationConfig("tri-stub-server"))
				.registry(registryConfig)
				.protocol(new ProtocolConfig(CommonConstants.TRIPLE, 50051))
				.service(service)
				.start();
		System.out.println("Dubbo triple stub server started");

		System.in.read();

you can paste your code for further discuss.

lineng-hao-jie · 2024-11-06T07:59:15Z

Is it possible that it is related to the combination of configuration and programming? In my case, only the service exposure is achieved through programming, while the rest are through configuration. The specific configurations are as follows:

    <dubbo:application name="travel-wuling" owner="travel-wuling" version="1.0.0" environment="product" >
        <dubbo:parameter key="qos.enable" value="false"/>
    </dubbo:application>
    <dubbo:registry id="registry" address="nacos://${nacos.host}:${nacos.port}?namespace=${nacos.namespace.dubbo}-${nacos.env}&amp;username=${nacos.username}&amp;password=${nacos.password}" />
    <dubbo:protocol name="dubbo" port="${dubbo.port.prefix}185" />
    <dubbo:provider delay="-1" timeout="10000" retries="0" loadbalance="roundrobin" />
    <dubbo:consumer check="false" />

Code snippet of service exposure:

...
       ServiceConfig service = new ServiceConfig<>(); 
        service.setApplication(application);
        service.setRegistry(registry); 
        service.setProtocol(protocol); 
        service.setInterface(cls);
        service.setRef(bean);
        service.setVersion("1.0.0");
        service.export();
...

wcy666103 · 2024-11-06T08:25:34Z

Is it possible that it is related to the combination of configuration and programming? In my case, only the service exposure is achieved through programming, while the rest are through configuration. The specific configurations are as follows:

    <dubbo:application name="travel-wuling" owner="travel-wuling" version="1.0.0" environment="product" >
        <dubbo:parameter key="qos.enable" value="false"/>
    </dubbo:application>
    <dubbo:registry id="registry" address="nacos://${nacos.host}:${nacos.port}?namespace=${nacos.namespace.dubbo}-${nacos.env}&amp;username=${nacos.username}&amp;password=${nacos.password}" />
    <dubbo:protocol name="dubbo" port="${dubbo.port.prefix}185" />
    <dubbo:provider delay="-1" timeout="10000" retries="0" loadbalance="roundrobin" />
    <dubbo:consumer check="false" />

Code snippet of service exposure:

...
       ServiceConfig service = new ServiceConfig<>(); 
        service.setApplication(application);
        service.setRegistry(registry); 
        service.setProtocol(protocol); 
        service.setInterface(cls);
        service.setRef(bean);
        service.setVersion("1.0.0");
        service.export();
...

You can debug or print out if the configuration parameters you got programmatically are correct.

lineng-hao-jie · 2024-11-06T08:43:13Z

The code for service exposure should be fine. It has been running normally from version 2.5.1 to 2.7.9, and all the way to 3.2.10/3.2.16. Even the interface - level service registration of 3.3.1 can also operate normally.

In addition, debugging was also performed in version 3.3.1, and it was found that the line in the problem description returned directly (line 1302 of DefaultApplicationDeployer).

   private void doExportMetadataService() {
        if (!isStarting() && !isStarted() && !isCompletion()) {
            return;
        }
        for (DeployListener<ApplicationModel> listener : listeners) {
            ...
        }
    }

Furthermore, if a "dubbo:service" configuration item is added to the configuration file, the instance - level service registration will eventually be normal as well.For example:

<dubbo:service interface="com.huntlee.travel.ai.llm.agent.api.DubboBug" id="dubboBugService" ref="dubboBug"/>

lineng-hao-jie · 2024-11-06T09:51:03Z

test.zip
Test execution: DubboBoost::boot, four scenarios were tested respectively:
1.dubbo 3.2.16

dubbo. properties:register-mode=interface, ok
dubbo. properties:register-mode=instance , ok

2.dubbo 3.3.1

dubbo. properties:register-mode=interface , ok
dubbo. properties:register-mode=instance, no ok

laywin · 2024-11-07T11:41:01Z

i think there is bug.

your case is special, config combine xml and program. when spring container started, there is no service config in xml, so missed the register process. then service export programmatically.

in past version there is a schedule to register the instance, so it can be registered successfully. but now it bypassed by a condition. i will try to fix it.

lineng-hao-jie · 2024-11-07T14:49:35Z

thanks!

lineng-hao-jie added component/need-triage Need maintainers to triage type/need-triage Need maintainers to triage labels Nov 5, 2024

github-project-automation bot moved this to Todo in Dubbo Board Nov 5, 2024

github-project-automation bot added this to Dubbo Board Nov 5, 2024

lineng-hao-jie changed the title ~~[Bug] dubbo 3.3.x 编程方式服务注册时，应用级别服务注册无效~~ [Bug] When registering services programmatically in Dubbo 3.3.x, the instance - level service registration is invalid. Nov 5, 2024

laywin linked a pull request Nov 7, 2024 that will close this issue

fix judgment for registry configed in DefaultApplicationDeployer #14874

Open

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Bug] When registering services programmatically in Dubbo 3.3.x, the instance - level service registration is invalid. #14859

[Bug] When registering services programmatically in Dubbo 3.3.x, the instance - level service registration is invalid. #14859

lineng-hao-jie commented Nov 5, 2024

laywin commented Nov 6, 2024

lineng-hao-jie commented Nov 6, 2024

wcy666103 commented Nov 6, 2024

lineng-hao-jie commented Nov 6, 2024

lineng-hao-jie commented Nov 6, 2024

laywin commented Nov 7, 2024

lineng-hao-jie commented Nov 7, 2024

[Bug] When registering services programmatically in Dubbo 3.3.x, the instance - level service registration is invalid. #14859

[Bug] When registering services programmatically in Dubbo 3.3.x, the instance - level service registration is invalid. #14859

Comments

lineng-hao-jie commented Nov 5, 2024

Pre-check

Search before asking

Apache Dubbo Component

Dubbo Version

Steps to reproduce this issue

What you expected to happen

Anything else

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

Code of Conduct

laywin commented Nov 6, 2024

lineng-hao-jie commented Nov 6, 2024

wcy666103 commented Nov 6, 2024

lineng-hao-jie commented Nov 6, 2024

lineng-hao-jie commented Nov 6, 2024

laywin commented Nov 7, 2024

lineng-hao-jie commented Nov 7, 2024