[Bug] Unable to perceive the latest subscription services

[6Glory9]

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.2.12

Steps to reproduce this issue

1. Get two instances here, one of which is about to die.
2. Both instances establish NettyConnectionClient, synchronised connection server appears to wait. At this point one of the instances is offline. The local nacos local cache is already listening for the latest metadata info.
3. Wait for all the NettyConnectionClient to complete, at which point the subscription relationship is done. Unable to trigger

What you expected to happen

Refreshing the service

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

[AlbumenJ]

We need a better way to get and listen service in one time. But maybe nacos not support?

[finefuture]

Maybe we can adjust the order of events, such as registering a listener first and then getting the instance list for notify.

[AlbumenJ]

Maybe we can adjust the order of events, such as registering a listener first and then getting the instance list for notify.

1. Will zk work as expected?
2. Will nacos work as expected?

[finefuture]

Maybe we can adjust the order of events, such as registering a listener first and then getting the instance list for notify.

1. Will zk work as expected?
2. Will nacos work as expected?

I think this will work, and I am currently drawing this flowchart.

[marmot-z]

Is this a problem? When the first service instance change event takes a long time to process, the second service instance change event will not be processed, causing the consuming application to still store the old service instance information locally (a normal service instance and an offline service instance)

If this is the case, it doesn't seem to cause too much of a problem? Because when the service provider makes a service call, the load balancing link will check whether the invoker is connected. If it is not connected, it will be kicked out of the validInvokers list. As long as there is an available invoker, the RPC request will not fail.