[Q&A][Java SDK (Component)] 3.3.4 After upgrading from Dubbo 2 to Dubbo 3, requests to a service with multiple consumers get stuck during consumer initialization after the service is registered with Nacos. Is there a recommended solution?

[lllichen]

Pre-check

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

Apache Dubbo Component

Java SDK (apache/dubbo)

Details

Background

After upgrading our application from Dubbo 2 to Dubbo 3, we found that an
application containing many Dubbo consumers may receive HTTP traffic before all
Dubbo consumers have finished initialization.

The application is also registered with Spring Cloud Nacos Discovery to receive
HTTP traffic from an upstream gateway.

This problem did not occur, or was not noticeable, when we were using Dubbo 2
with JDK 8.

Environment

• JDK: 21.0.7
• Spring Boot: 2.6.11
• Dubbo: 3.3.4
• Spring Cloud Alibaba Nacos Discovery: 2021.0.4.0
• Registry: Nacos
• Dubbo migration mode: FORCE_INTERFACE
• Dubbo metadata type: remote

Nacos is used for both:

1. Dubbo service discovery
2. Spring Cloud service discovery for incoming HTTP traffic

The application contains many @DubboReference consumers. Lazy initialization
is not enabled, and the previous init = false settings have been removed.

Some references use check = false, because the application should still be
able to start when an optional provider is temporarily unavailable.

Problem

During startup, the embedded Tomcat server starts before the Dubbo application
and all consumer references have completed startup.

Spring Cloud Nacos may register the HTTP service instance after the web server
has started. The upstream gateway can then discover the instance and send HTTP
requests to it.

At this time, Dubbo is still initializing consumers, including operations such
as:

• Creating ReferenceConfig
• Subscribing to provider addresses from Nacos
• Receiving provider notifications
• Creating invokers and cluster invokers
• Establishing network connections

When an HTTP request invokes one of these consumers during this period, the
request may block during consumer initialization or service discovery. In some
cases, the request duration is close to the configured Dubbo timeout.

After all consumers have been initialized, subsequent requests return to normal.

Startup timeline

The following is an example from our startup log:

10:26:34.405 Nacos registration was delayed by our workaround
10:26:38.105 Tomcat started on port 8099
10:26:42.177 Dubbo health probe: module is not ready
10:26:47.918 Dubbo Module has started
10:26:47.926 Dubbo Application is ready
10:26:48.042 Dubbo Module/Application has completed
10:26:48.154 Spring Boot application Started
10:26:48.175 Spring Cloud Nacos instance registered
10:26:49.793 First HTTP request arrived

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

[lllichen]

please help me

[hossiendehghan989]

check=false is not a readiness mechanism; it only prevents a missing optional provider from failing reference creation. It does not stop an HTTP request from blocking while the reference/subscription is still being built.

The fix should be to gate Spring Cloud/Nacos HTTP registration on application readiness, rather than adding a startup sleep:

1. Keep the instance invisible to the gateway during bootstrap (disable automatic Spring Cloud registration, or register it as OUT_OF_SERVICE/with a readiness-aware instance state).
2. Expose a readiness probe that becomes healthy only after the Dubbo Module/Application has started and the references required by the HTTP endpoints have been created. Keep liveness separate.
3. Register/enable the Nacos instance only after that readiness transition, and deregister it on shutdown.
4. If some references are intentionally optional, keep check=false, but make the endpoint return a deliberate 503/controlled fallback until that provider is available; do not let the first request trigger hidden initialization.

This removes the race without coupling correctness to timing. The useful verification is a cold start with the gateway polling discovery: no traffic should be routed before readiness, and after readiness a request should not be the first operation that creates a ReferenceConfig or waits for provider notification. Also confirm that the Dubbo and Spring Cloud Nacos registrations are not accidentally sharing a single readiness state.