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

fix: set default 0 when get method timeout config #1422

Merged
merged 2 commits into from
Jul 29, 2024

Conversation

Lo1nt
Copy link
Collaborator

@Lo1nt Lo1nt commented Jun 13, 2024

Motivation:

The method-level timeout config is Integer type which accepts null value.

So if we add method config and set the method-level timeout to null, a timeout=null might be pub onto registry.

Say, 1.1.1.1:12200?rpcVer=12300&serialization=hessian&app_name=demo&[echo]=[clientTimeout#null].

When dealing with null value, some of the implementations may omit catching exception when doing Integer.parseInt(null), leading to unexpected startup error.

Modification:

As both null and 0 are meaningless in SOFARPC (might only indicate 'not set', but we do not care), I set method.getTimeout a default 0 return value if null.

Result:

Focus on
com.alipay.sofa.rpc.registry.sofa.SofaRegistryHelper#convertProviderToUrls
com.alipay.sofa.rpc.registry.mesh.SofaRegistryHelper#convertProviderToUrls
will not get and pub a null timeout value any more.

String key = "[" + methodName + "]";
String value = "[" + KEY_TIMEOUT + "#" + methodConfig.getTimeout() + "]";
sb.append(getKeyPairs(key, value))

Summary by CodeRabbit

  • Bug Fixes

    • Ensured that the timeout configuration returns a default value of 0 when not set.
  • Tests

    • Added new tests to verify timeout configuration behavior.

@sofastack-cla sofastack-cla bot added bug Something isn't working question Further information is requested cla:yes CLA is ok size/M labels Jun 13, 2024
@Lo1nt Lo1nt requested a review from OrezzerO June 13, 2024 08:18
Copy link
Contributor

coderabbitai bot commented Jun 13, 2024

Walkthrough

The changes improve timeout management in the codebase. They modify the MethodConfig class to return a default timeout of 0 if the timeout is unset, and expand test coverage. New tests check for the presence and correctness of timeout configurations using ProviderConfig. The changes ensure smoother and more predictable behavior in event of null timeout values.

Changes

File Path Change Summary
core/api/src/main/java/com/alipay/sofa/rpc/config/MethodConfig.java Modified getTimeout method to return a default value of 0 if the timeout field is null.
core/api/src/test/java/com/alipay/sofa/rpc/std/config/AbstractInterfaceConfigTest.java Added ProviderConfig import and a new test method testMethodTimeout to verify correct timeout behavior.
registry/registry-sofa/src/test/java/com/alipay/sofa/rpc/registry/sofa/SofaRegistryHelperTest.java Included creation and manipulation of a new ProviderConfig object to test method timeout assertions.

Sequence Diagram(s)

Diagrams are not necessary as the changes are primarily related to configuration and testing enhancements.

Poem

In lines of code where time is told,
A timeout set if null is old.
With tests now clear, no bugs to fear,
Our methods stand both strong and bold.
A rabbit cheers, in quiet leaps,
For code improvements it now keeps.


Tip

Early access features: enabled

We are currently testing the following features in early access:

  • OpenAI gpt-4o model for code reviews and chat: OpenAI claims that this model is better at understanding and generating code than the previous models. We seek your feedback over the next few weeks before making it generally available.

Note:

  • You can enable or disable early access features from the CodeRabbit UI or by updating the CodeRabbit configuration file.
  • Please join our Discord Community to provide feedback and report issues.
  • OSS projects are currently opted into early access features by default.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@Lo1nt Lo1nt requested review from chuailiwu and EvenLjj June 13, 2024 08:18
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between d163820 and e56de78.

Files selected for processing (3)
  • core/api/src/main/java/com/alipay/sofa/rpc/config/MethodConfig.java (1 hunks)
  • core/api/src/test/java/com/alipay/sofa/rpc/std/config/AbstractInterfaceConfigTest.java (2 hunks)
  • registry/registry-sofa/src/test/java/com/alipay/sofa/rpc/registry/sofa/SofaRegistryHelperTest.java (1 hunks)
Files skipped from review due to trivial changes (1)
  • core/api/src/main/java/com/alipay/sofa/rpc/config/MethodConfig.java
Additional comments not posted (1)
core/api/src/test/java/com/alipay/sofa/rpc/std/config/AbstractInterfaceConfigTest.java (1)

26-26: The import of ProviderConfig is appropriate as it supports the new test method added.

Comment on lines +153 to +163

ProviderConfig<?> providerConfig2 = new ProviderConfig<>();
providerConfig2.setMethods(new HashMap<>());
providerConfig2.getMethods().put("test", new MethodConfig().setTimeout(null));
Assert.assertNotNull(providerConfig2.getTimeout());
String s4 = SofaRegistryHelper.convertProviderToUrls(providerConfig2, serverConfig);
Assert.assertNotNull(s3);
ProviderInfo providerInfo4 = SofaRegistryHelper.parseProviderInfo(s4);
Assert.assertEquals(0, providerInfo4.getDynamicAttr(".test.timeout"));
Assert.assertFalse(providerConfig2.hasTimeout());

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The modifications in the convertProviderToUrls method correctly handle the scenario where a method's timeout is null, ensuring a default value of 0 is used. This aligns with the PR's objectives to prevent null timeout values from being published. Consider verifying this behavior in integration tests to ensure it behaves as expected across different configurations.

Would you like assistance in setting up integration tests for this scenario?

@sofastack-cla sofastack-cla bot added size/S and removed size/M labels Jul 2, 2024
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between e56de78 and 2ffde4c.

Files selected for processing (1)
  • core/api/src/test/java/com/alipay/sofa/rpc/std/config/AbstractInterfaceConfigTest.java (2 hunks)

Comment on lines +54 to +68
@Test
public void testMethodTimeout() {
MethodConfig config = new MethodConfig();
config.setTimeout(null);

ProviderConfig p = new ProviderConfig();
p.setMethods(new HashMap<>());
p.getMethods().put("test", config);

try {
Assert.assertFalse(p.hasTimeout());
} catch (Exception e) {
Assert.fail("exception should not appears: " + e.getMessage());
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding more test scenarios for robust testing.

The test method testMethodTimeout effectively checks the behavior when timeout is null. Consider adding more scenarios to ensure robust testing, such as verifying the actual timeout value used by the system when null is set.

Would you like me to help create additional test cases for this scenario?

Copy link
Collaborator

@EvenLjj EvenLjj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@OrezzerO
Copy link
Contributor

OrezzerO commented Jul 8, 2024

I think we still need to discuss the following points to reach a consensus:

  1. In the URL exposed by the registry center, the timeout represents the server's recommended timeout. If the client does not configure it, the server's recommended timeout is used. However, the client has a default timeout, which is not 0. Therefore, should we expose the server default timeout instead of 0?

  2. What is the meaning of setting the timeout to 0? This is not clear. Does it mean no timeout or using the default timeout?

@Lo1nt
Copy link
Collaborator Author

Lo1nt commented Jul 10, 2024

I think we still need to discuss the following points to reach a consensus:

  1. In the URL exposed by the registry center, the timeout represents the server's recommended timeout. If the client does not configure it, the server's recommended timeout is used. However, the client has a default timeout, which is not 0. Therefore, should we expose the server default timeout instead of 0?
  2. What is the meaning of setting the timeout to 0? This is not clear. Does it mean no timeout or using the default timeout?

@OrezzerO
Firstly, I bet this logic is not interfered this time. Currently, the client timeout is decided under following step:

1. request level, set from invoke context.
2. client config.
3. server config, from subscribe data.
4. client default value.

And, for each of the above step, only when a positive value appears will it stop and active, null or 0 will let it step to next config. Besides, actually interface level config use int type timeout, which does not allow null value.

ref: com.alipay.sofa.rpc.client.AbstractCluster#resolveTimeout

Secondly, I dont think "no timeout" which lead to endless blocking is appropriate within this scope. As we dont want to witness thread leakage due to blocking and waiting for response that might not come due to some error. So, in my opinion, value no greater than 0 is, actually, meaningless and should be replaced with default value.
Even if there are scenarios about waiting until a response comes, we should still consider when to recycle this rpc call task instead of just letting it sleep and wait.

@OrezzerO
Copy link
Contributor

First, I contend that this PR is "acceptable" because it doesn't alter the existing logic.

Regarding the first point I mentioned earlier:

As you stated:

A value no greater than 0 is, in fact, meaningless and should be replaced with the default value.
So, why expose a meaningless number in the registry? Exposing the default timeout or not exposing anything at all would be more meaningful.

Regarding the second point I mentioned earlier:

When users set 0 for the timeout, there could be three scenarios:

  1. When the timeout is 0, the client won't wait.
  2. When the default timeout is used, the client will wait until the default timeout elapses.
  3. The client will wait indefinitely.
    Each scenario may apply in certain circumstances. The framework should inform users what will occur when they set 0 for the timeout.

To draw a conclusion, I have the following suggestions for this PR:
Expose the default timeout or don't expose anything.
Add comments in ConsumerConfig and ProviderConfig to clarify what will happen when 0 is set for the timeout.

BTW , consider what will happen when default timeout is 0 ? The client won't wait. The default timeout and user defined timeout acts differently.

Copy link
Contributor

@OrezzerO OrezzerO left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Lo1nt
Copy link
Collaborator Author

Lo1nt commented Jul 17, 2024

too long to reference
Exposing the default timeout or not exposing anything at all would be more meaningful.
Result for users setting 0 for the timeout

@OrezzerO Welp, actually the whole project already made its choice. SOFARPC currently, in the area of timeout, could not distinguish 0 value from no value is set.

As for default or 0 value

Absolutely, so it will not currently be exposed to the public, there is the logic to ensure that:

if (providerConfig.getTimeout() > 0) {
        sb.append(getKeyPairs(ATTR_TIMEOUT, providerConfig.getTimeout()));
}

ref : com.alipay.sofa.rpc.registry.sofa.SofaRegistryHelper#convertProviderToUrls

I guess this is designed for the int type timeout which 0 value might indicate user set 0 or user didnt set any value.

However, the client side will always set a 0 value if there is no meaningful value (cuz it is a int type), so the logic for client side is to accept a positive integer only. As I hv mentioned before.

This mechanism achieves that timeout should be an integer greater than 0, or we regard it as not set.

For the second concern

So now we got the conclusion, 0 will indicate for not set.

@EvenLjj EvenLjj merged commit ff2471e into sofastack:master Jul 29, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working cla:yes CLA is ok question Further information is requested size/S
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants