[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.
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.
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.
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.
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.
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:
TaskMapfor 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)