Hi, woule you like to leave a e-mail here, we would like to invite you to become an Apache Dubbo Committer.

I understand the issue in you case in #14200, but I don't think we can change the mapping key directly by adding group and version to it. This is by design (only include service interfice) and change the key would bring breaking change to applications using older versions.

Service A and B have same interface com.test.InterfaceXXX, their dubbo.application.metadata-type are same local, but group or version are different,
Consumer C only invokes com.test.InterfaceXXX of service A, the connection between C and A is allowable, but the connection between C and B is forbidden by firework.
When consumer C created dubbo reference of service A, it will get mapping metadata which mapping key is com.test.InterfaceXXX, of course the result from metadata center has both A and B
Consumer C will try to connect to both A and B to building reference of A (their metadata-type are both local), but it will be always failure because the firework will break down the connection from C to B.

Was Consumer C consuming services of all versions and groups with group="*" and version="*"? Can we just change Cosumer C and tell it to only consume service instances of certain group and version, this can make it simple.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

Hi, woule you like to leave a e-mail here, we would like to invite you to become an Apache Dubbo Committer.

zrlw@sina.com

Service A and B have same interface com.test.InterfaceXXX, their dubbo.application.metadata-type are same local, but group or version are different,
Consumer C only invokes com.test.InterfaceXXX of service A, the connection between C and A is allowable, but the connection between C and B is forbidden by firework.
When consumer C created dubbo reference of service A, it will get mapping metadata which mapping key is com.test.InterfaceXXX, of course the result from metadata center has both A and B
Consumer C will try to connect to both A and B to building reference of A (their metadata-type are both local), but it will be always failure because the firework will break down the connection from C to B.

Was Consumer C consuming services of all versions and groups with group="*" and version="*"? Can we just change Cosumer C and tell it to only consume service instances of certain group and version, this can make it simple.

Consumer C only consume service A by @DubboReference(group="nameOfServiceA", version="1.0.0")

I understand the issue in you case in #14200, but I don't think we can change the mapping key directly by adding group and version to it. This is by design (only include service interfice) and change the key would bring breaking change to applications using older versions.

the issue might be alleviated if we catch the RemotingException during the while statement of method ServiceDiscoveryRegistry#subscribeURLs, but it will introduce other issues if parameter timeout might be too long or there are too many services that have the same interface name but the consumer C could not be build connection to them .

To be compatible with old applications using old version, adding group names for each interface to the metadata of the instance and filtering out mismatched service instances from ServiceDiscoveryRegistry#subscribeURLs is another alternative solution, but it violates the design intention of the application level registration pattern to reduce metadata information.

Service A and B have same interface com.test.InterfaceXXX, their dubbo.application.metadata-type are same local, but group or version are different,
Consumer C only invokes com.test.InterfaceXXX of service A, the connection between C and A is allowable, but the connection between C and B is forbidden by firework.
When consumer C created dubbo reference of service A, it will get mapping metadata which mapping key is com.test.InterfaceXXX, of course the result from metadata center has both A and B
Consumer C will try to connect to both A and B to building reference of A (their metadata-type are both local), but it will be always failure because the firework will break down the connection from C to B.

Was Consumer C consuming services of all versions and groups with group="*" and version="*"? Can we just change Cosumer C and tell it to only consume service instances of certain group and version, this can make it simple.

Consumer C only consume service A by @DubboReference(group="nameOfServiceA", version="1.0.0")

If Consumer C consumes only @DubboReference(group="nameOfServiceA", version="1.0.0") and Service A and Service B have different group or version,

Service A and B have same interface com.test.InterfaceXXX, their dubbo.application.metadata-type are same local, but group or version are different,

then Consumer C would only call either A or B, depending on which one matches @DubboReference(group="nameOfServiceA", version="1.0.0"), C would not call both A and B.

The process of creating dubboReference of serivce A:

1. Obtain all application names corresponding to conditions (for nacos: dataId="com.test.InterfaceXXX", group="mapping") from the metadata center.
2. Query all instances under all application names obtained by step 1 from registry center.
3. Loop through all the instances obtained by step 2, if metadata type is local, then connect to the corresponding service to retrieve the metadata. At here, it will try to build connection to service B, after 3 seconds, the reference creation will be failed by RemotingException.

For each service instance that consumer C has not network access privileges, the method AbstractServiceDiscovery#getRemoteMetadata always try calling getRemoteMetadata 3 times and wait 1 second from each time.

3. Loop through all the instances obtained by step 2, if metadata type is local, then connect to the corresponding service to retrieve the metadata. At here, it will try to build connection to service B, after 3 seconds, the reference creation will be failed by RemotingException.

I see the problem in your case here.