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

#2080 Add new V8 params to fine-tune Polly's circuit-breaker behavior #2081

Open
wants to merge 7 commits into
base: develop
Choose a base branch
from

Conversation

RaynaldM
Copy link
Collaborator

@RaynaldM RaynaldM commented May 29, 2024

Closes #2080

This PR adds 2 new parameters in QoSOptions to fine-tune circuit-breaker behavior 👉

  • FailureRatio: The failure-success ratio that will cause the circuit to break/open.
  • SamplingDuration: The time period over which the failure-success ratio is calculated (in seconds).

@RaynaldM RaynaldM self-assigned this May 29, 2024
@RaynaldM RaynaldM added feature A new feature small effort Likely less than a day of development effort. QoS Ocelot feature: Quality of Service aka Polly Configuration Ocelot feature: Configuration labels May 29, 2024
@raman-m raman-m changed the title #2080 Adds parameters (in this case those of Polly V8) to fine-tune c… #2080 New V8 parameters to fine-tune Polly's circuit-breaker behavior May 29, 2024
@raman-m raman-m changed the title #2080 New V8 parameters to fine-tune Polly's circuit-breaker behavior #2080 Add new V8 params to fine-tune Polly's circuit-breaker behavior May 29, 2024
@raman-m
Copy link
Member

raman-m commented May 29, 2024

Great! Which version are you planning to release it in?

Please note that the PR depends on #2073, which needs to be merged before this PR. Therefore, this feature branch should be rebased after the merging of #2073, and ideally, after #2079 is merged as well.

It appears that it won't be included in version 23.3, but rather in version 24.0, which is the next release following v23.3.
Is this delivery acceptable to you?

@RaynaldM
Copy link
Collaborator Author

Great! Which version are you planning to release it in?

Please note that the PR depends on #2073, which needs to be merged before this PR. Therefore, this feature branch should be rebased after the merging of #2073, and ideally, after #2079 is merged as well.

It appears that it won't be included in version 23.3, but rather in version 24.0, which is the next release following v23.3. Is this delivery acceptable to you?

Yes, @raman-m, you can add this when you want

@raman-m raman-m added the 2023 Annual 2023 release label Jun 11, 2024
@raman-m raman-m added this to the Annual 2023 milestone Jun 11, 2024
@raman-m
Copy link
Member

raman-m commented Jun 11, 2024

@RaynaldM
Please resolve conflicts!
PR has been added to v24.0 milestone, current release

@raman-m
Copy link
Member

raman-m commented Jun 13, 2024

@RaynaldM Conflicts!

@raman-m raman-m force-pushed the 2080-adds-parameters-in-this-case-those-of-polly-v8-to-fine-tune-circuit-breaker-behavior branch from 1de22fd to f69831a Compare June 14, 2024 17:52
@raman-m raman-m removed the small effort Likely less than a day of development effort. label Jun 14, 2024
@raman-m raman-m requested review from raman-m and ggnaegi and removed request for raman-m June 19, 2024 16:04
@raman-m raman-m added Oct'24 October 2024 release and removed 2023 Annual 2023 release labels Aug 12, 2024
@raman-m raman-m modified the milestones: Annual 2023, September'24 Aug 12, 2024
@raman-m
Copy link
Member

raman-m commented Aug 12, 2024

Let's assign this to the Sep'24 milestone since the Annual 2023 milestone is already quite overloaded, and we need to reduce the scope of work for 2023.

@raman-m raman-m added Dec'24 December 2024 release and removed Oct'24 October 2024 release labels Oct 26, 2024
@raman-m raman-m modified the milestones: October'24, Autumn'24 Oct 26, 2024
@raman-m raman-m force-pushed the 2080-adds-parameters-in-this-case-those-of-polly-v8-to-fine-tune-circuit-breaker-behavior branch from 8a6926a to 3199588 Compare November 1, 2024 17:56
Copy link
Member

@raman-m raman-m left a comment

Choose a reason for hiding this comment

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

The absence of tests for the new properties is a significant concern for approval.
I recommend further work on the PR.

For Your Information: The feature branch has been successfully rebased onto the develop branch, as of November 1st, just today

@@ -35,13 +35,18 @@ Then add the following section to a Route configuration:
"QoSOptions": {
"ExceptionsAllowedBeforeBreaking": 3,
"DurationOfBreak": 1000,
"TimeoutValue": 5000
"TimeoutValue": 5000,
"FailureRatio": .8 // .8 = 80% of failed, this is default value
Copy link
Member

Choose a reason for hiding this comment

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

No comma❗

Suggested change
"FailureRatio": .8 // .8 = 80% of failed, this is default value
"FailureRatio": .8, // .8 = 80% of failed, this is default value

"TimeoutValue": 5000
"TimeoutValue": 5000,
"FailureRatio": .8 // .8 = 80% of failed, this is default value
"SamplingDuration": 10000 // The time period over which the failure-success ratio is calculated (in milliseconds), default is 10000 (10s)
Copy link
Member

Choose a reason for hiding this comment

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

  1. Better to add new properties docs below, after line 45.
  2. You are wrong regarding default value! According to the docs for SamplingDuration, the default value is 30 seconds! So, we override library value by our custom one (10s). I believe we must assign lib value in QoSOptions

FailureRatio = 0.8,
SamplingDuration = TimeSpan.FromSeconds(10),
FailureRatio = options.FailureRatio,
SamplingDuration = TimeSpan.FromMilliseconds(options.SamplingDuration),
Copy link
Member

Choose a reason for hiding this comment

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

Both SamplingDuration and BreakDuration are TimeSpans, so they can be initialized from milliseconds.
Not an issue! FYI

FailureRatio = failureRatio;
}

public QoSOptions(
Copy link
Member

Choose a reason for hiding this comment

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

Why did you add both constructors? I don't see any changes in the Creators' logic.
It appears these constructors were added solely for testing purposes. I would suggest switching to QoSOptionsBuilder and removing these two constructors.
Therefore, you will need to update QoSOptionsBuilder by adding new initialization methods.

/// </value>
public int SamplingDuration { get; } = 10000;
Copy link
Member

Choose a reason for hiding this comment

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

I disagree to assign custom default value which differs from the lib one!
So, according to the docs for SamplingDuration, the default value is 30 seconds! So, we override library value by our custom one (10s). I believe we must assign lib value in QoSOptions

/// <value>
/// An <see cref="double"/> ratio of exceptions/requests (0.8 means 80% failed of all sampled executions).
/// </value>
public double FailureRatio { get; } = .8;
Copy link
Member

Choose a reason for hiding this comment

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

Actually FailureRatio has the default value is 0.1
So, I don't recommend to override library settings!

Comment on lines +109 to +112
public bool IsValid() =>
ExceptionsAllowedBeforeBreaking <= 0 ||
ExceptionsAllowedBeforeBreaking >= 2 && DurationOfBreak > 0 && !(FailureRatio <= 0) &&
!(FailureRatio > 1) && SamplingDuration > 0;
Copy link
Member

Choose a reason for hiding this comment

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

Is it used for JSON config validation?

@@ -38,7 +38,7 @@ public override void Dispose()
public void Should_not_timeout()
{
var port = PortFinder.GetRandomPort();
var route = GivenRoute(port, new QoSOptions(10, 500, 1000, null), HttpMethods.Post);
var route = GivenRoute(port, new QoSOptions(10, 500, .5, 5, 1000, null), HttpMethods.Post);
Copy link
Member

Choose a reason for hiding this comment

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

Test readability is low❗

We have to switch to QoSOptionsBuilder in tests avoiding direct usage of constructors!
With QoSOptionsBuilder test readability will be excellent. 😉

@raman-m
Copy link
Member

raman-m commented Nov 1, 2024

Raynald, please note that this PR is a successor of #2073, which contains numerous changes to the same logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Configuration Ocelot feature: Configuration Dec'24 December 2024 release feature A new feature QoS Ocelot feature: Quality of Service aka Polly
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FailureRatio and SamplingDuration parameters of Polly V8 circuit-breaker
2 participants