-
Notifications
You must be signed in to change notification settings - Fork 31
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
[Stability] Garbage collect polls for all views < latest-2 #2226
Conversation
This reverts commit 90ea36d.
I have tested this in multiple runs and it works well. Includes view sync runs, and runs where 3 (view_sync)+1 nodes are down in a row |
// Remove all entries in the task map that are polling for a view less than or equal to `view_number - 2`. | ||
let view_minus_2 = view_number.saturating_sub(2); | ||
let range = task_map.range(..view_minus_2); | ||
for (view, task) in range { | ||
// Cancel the old task by sending a message to it. If the task already exited we expect an error | ||
let _res = task | ||
.send(ConsensusIntentEvent::CancelPollForProposal(*view)) |
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 Can we make this a function that takes the event, maybe as a fn like event_fn: fn(view: u64) -> ConsensusIntentEvent
and then the function could just do range.map(event_fn)
. Mostly just making this a function so this code isn't copy pasted a bunch of times
@@ -768,8 +770,6 @@ impl<TYPES: NodeType + 'static> ConnectedNetwork<Message<TYPES>, TYPES::Signatur | |||
); | |||
|
|||
// TODO ED Need to handle canceling tasks that don't receive their expected output (such a proposal that never comes) | |||
// TODO ED Need to GC all old views, not just singular views, could lead to a network leak | |||
|
|||
match event { | |||
ConsensusIntentEvent::PollForProposal(view_number) => { |
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.
I think we should also GC the view sync stuff here, it's possible we just don't hit view sync for a long time, and we'd be running the view sync polling task for a ton of views. In fact if maybe we can just cancel all old task regardless of what we are getting the new polling intent for. Basically every time we start to poll for a new view number we can GC old view task from all the task maps
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.
We can do this but I have to be careful; certain things like transactions and leaders we poll way ahead for. If we start polling for txes in view n+3, polls for other things in view n would get cancelled before we have everything resolved
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.
Agree that's a good point we need to be careful. I was more thinking only for the big things, like proposal and view sync certificates. On second thought maybe it's best to have a specific event like CancelOldPolls
which we inject when we update our view that cancels the old view polling. That way we have one entry point for GCing but don't have to piggy back on the old events which might have weirdness like you mentioned.
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.
I don't see anything functionally wrong with doing the GC this way. We guarantee that we have at most 2 of each task at any given time. That seems reasonable.
I had some comments on how we might simplify this but IMO this is a good improvement that we should get in for the next deployment tomorrow
These are good changes, I will have them out today |
Closes #2225
This PR:
TaskMap
for all data types to be aBTreeMap
(which is ordered)This PR does not:
Address any other webserver-related errors or bugs.
Key places to review:
Both files ! (minus the one which just got linted)