-
Notifications
You must be signed in to change notification settings - Fork 101
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
Do not check SSR State when Snapshotter should be stopped #680
Conversation
@avestuk Thank you for your contribution. |
Thank you @avestuk for your contribution. Before I can start building your PR, a member of the organization must set the required label(s) {'reviewed/ok-to-test'}. Once started, you can check the build status in the PR checks section below. |
@ishan16696 Anything I can do to help move this along? |
Hi @avestuk , |
Thanks @avestuk for PR, |
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 !!
As requested in this comment: #680 (comment), please rebase this PR on latest master. |
Allows type checking of channel interactions
I think that closing the channel makes it clearer that this channels purpose has been fulfilled and it no longer needs to be considered. All the places that use the channel are recieving all values from the channel so they will continue to function in the same way
The snapshotter is not set to active state until an initial delta snapshot or a fullsnapshot has been taken. If a leadership election takes place while the snapshot is being taken and the current leader loses that election, then handleSsrRequest does not send on the ssrStopCh. This in turn causes ssr.snapshotEventHandler to never return and snapshots would continue to be taken.
e59dd3f
to
c90aa01
Compare
Thanks very much @ishan16696 I've rebased on latest master. |
/hold until #716 is merged. |
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!!, thanks for rebasing the PR
PR #716 will take some time as it also need to resolve merge conflicts, let's not block this PR. Talked to @shreyas-s-rao and he is fine with it. |
* Specify send/recv Allows type checking of channel interactions * Close instead of sending on channel I think that closing the channel makes it clearer that this channels purpose has been fulfilled and it no longer needs to be considered. All the places that use the channel are recieving all values from the channel so they will continue to function in the same way * Do not check ssr state in handleSsrStopRequest The snapshotter is not set to active state until an initial delta snapshot or a fullsnapshot has been taken. If a leadership election takes place while the snapshot is being taken and the current leader loses that election, then handleSsrRequest does not send on the ssrStopCh. This in turn causes ssr.snapshotEventHandler to never return and snapshots would continue to be taken.
* Specify send/recv Allows type checking of channel interactions * Close instead of sending on channel I think that closing the channel makes it clearer that this channels purpose has been fulfilled and it no longer needs to be considered. All the places that use the channel are recieving all values from the channel so they will continue to function in the same way * Do not check ssr state in handleSsrStopRequest The snapshotter is not set to active state until an initial delta snapshot or a fullsnapshot has been taken. If a leadership election takes place while the snapshot is being taken and the current leader loses that election, then handleSsrRequest does not send on the ssrStopCh. This in turn causes ssr.snapshotEventHandler to never return and snapshots would continue to be taken. Co-authored-by: Alex Vest <avestuk@gmail.com>
What this PR does / why we need it:
As reported in #676 we sometimes see that multiple snapshotters can be running at one time in a cluster.
I believe that the reason for this is that the snapshotter is not set to active state until an initial delta snapshot or a fullsnapshot has been taken. If a leadership election takes place while the snapshot is being taken and the current leader loses that election, then handleSsrRequest does not send on the ssrStopCh. This in turn causes ssr.snapshotEventHandler to never return and snapshots would continue to be taken.
Secondly I'm propsing a change to close the
ssrStopCh
rather than sending on it. This is to make it clear to the reader that the channel is no longer being used at this point.Lastly the function signature changes are simply adding further type annotations to the channels passed to functions to help readers understand where channels are being read from/sent to.
Which issue(s) this PR fixes:
Fixes #676
Special notes for your reviewer:
The reason why the ssrState was being checked is not apparent to me so I'd be delighted to be told why this might be an awful idea.
Release note: