Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make mapping key unique by add group and version to it #14201

Open
wants to merge 1 commit into
base: 3.2
Choose a base branch
from

Conversation

zrlw
Copy link
Contributor

@zrlw zrlw commented May 16, 2024

What is the purpose of the change

fixed #14200

Brief changelog

add group and version to mapping key

Verifying this change

Checklist

  • Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
  • Each commit in the pull request should have a meaningful subject line and body.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
  • Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
  • Add some description to dubbo-website project if you are requesting to add a feature.
  • GitHub Actions works fine on your own branch.
  • If this contribution is large, please follow the Software Donation Guide.

@zrlw zrlw force-pushed the 3.2-feature-buildUniqueMappingKey branch from 069c520 to 187c4da Compare May 16, 2024 09:28
@zrlw zrlw changed the title change mapping key to compatible colon separated format make mapping key unique by add group and version to it May 16, 2024
@chickenlj
Copy link
Contributor

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

@chickenlj
Copy link
Contributor

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.

@chickenlj
Copy link
Contributor

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.

Copy link

sonarcloud bot commented May 16, 2024

@zrlw
Copy link
Contributor Author

zrlw commented May 16, 2024

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

[email protected]

@zrlw
Copy link
Contributor Author

zrlw commented May 16, 2024

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")

@zrlw
Copy link
Contributor Author

zrlw commented May 16, 2024

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 .

@zrlw
Copy link
Contributor Author

zrlw commented May 17, 2024

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.

@chickenlj
Copy link
Contributor

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.

@zrlw
Copy link
Contributor Author

zrlw commented May 17, 2024

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.

@zrlw
Copy link
Contributor Author

zrlw commented May 17, 2024

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.

@chickenlj
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug] there are problems if mapping key only has service interface class name
2 participants