-
Notifications
You must be signed in to change notification settings - Fork 48
Add TryGetTokenForDataLossDetection method to avoid unnecessary CancellationTokenSource creation and Timer creation on every RPC #689
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
Add TryGetTokenForDataLossDetection method to avoid unnecessary CancellationTokenSource creation and Timer creation on every RPC #689
Conversation
…llationTokenSource creation - Added TryGetTokenForDataLossDetection() method to IWatchForRedisLosingAllItsData interface - Implemented the method in WatchForRedisLosingAllItsData to return token immediately if monitoring is active - Updated RedisPendingRequestQueue to use try method first, falling back to GetTokenForDataLossDetection - Refactored DequeueAsync to use centralized DataLossCancellationToken method instead of duplicating logic - Updated test implementations (RedisNeverLosesData and CancellableDataLossWatchForRedisLosingAllItsData) - Improves performance by avoiding CancellationTokenSource allocation when monitoring is already ready - Maintains backward compatibility with existing GetTokenForDataLossDetection method - Reduces code duplication by centralizing data loss cancellation token logic Resolves TODO comment in WatchForRedisLosingAllItsData.cs
f412257
to
df39b37
Compare
var token = watchForRedisLosingAllItsData.TryGetTokenForDataLossDetection(); | ||
if (token.HasValue) | ||
{ | ||
return token.Value; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This new code is about 10x faster than the below code.
The below code is almost always never executed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅ LGTM
Nits are very much non-blocking
return await localCopyOfTaskCompletionSource.Task.WaitAsync(cts.Token); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: extraneous blank line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
|
||
public CancellationToken? TryGetTokenForDataLossDetection() | ||
{ | ||
if (TaskCompletionSource.Task.IsCompleted && TaskCompletionSource.Task.Status == TaskStatus.RanToCompletion) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Not sure how I missed this before, but is there a reason TaskCompletionSource
is a public
field? Should we keep that one private if nothing is relying on accessing it directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait it is private:
I guess I can remove the private and fall back to halibut defaults that make it private.
Background
This is a simple change to reduce the amount of work we do. In most cases we will already have a Data Loss CT which means we can avoid creating multiple CTS and delayed tasks that will immediately throw.
Additionally the methods are updated such that we work on a consistent TaskCompletionSource since that value is replaced.
We are aiming to reduce as much work as possible in the normal case, to reduce queue overhead.
The AI wrote this:
How to review this PR
Quality ✔️
Pre-requisites