-
Notifications
You must be signed in to change notification settings - Fork 287
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
lib/worker(engine): refactor BaseWorker (Part I) #5520
Conversation
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. @@ Coverage Diff @@
## master #5520 +/- ##
================================================
- Coverage 56.2521% 56.1891% -0.0630%
================================================
Files 530 530
Lines 69880 69791 -89
================================================
- Hits 39309 39215 -94
+ Misses 26840 26837 -3
- Partials 3731 3739 +8 |
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
sinceLastAcked < m.timeoutConfig.WorkerTimeoutDuration { | ||
|
||
// We ignore the error here | ||
_ = m.asyncReloadMasterInfo(context.Background()) |
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.
Is it better to add a timeout, such as WorkerTimeoutDuration
, in case of leaving some stale goroutines even worker has exited. Besides why removing the context
parameter in this function
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.
Besides why removing the context parameter in this function
The semantics of CheckMasterTimeout
does not seem to require a context. It should always be non-blocking to avoid any surprises.
zap.String("master-id", m.masterID)) | ||
if !ok { | ||
// Reloads master info asynchronously. | ||
_ = m.asyncReloadMasterInfo(context.Background()) |
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.
ditto
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.
Do we also need to add a timeout here?
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 8993880
|
What problem does this PR solve?
Issue Number: ref #5521
What is changed and how it works?
MasterClient
into a separate package.OnMasterFailOver
.Reviewer's Guide
engine/lib/worker/master_client.go
.MasterClient
is the same as before, but with some asynchronous enhancement and minor bug fixes.OnMasterFailOver
does not harm the correctness of the business logic.Check List
Tests