-
Notifications
You must be signed in to change notification settings - Fork 56
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
[HOTFIX] Poll forever for latest data #2473
Conversation
@@ -325,7 +332,7 @@ impl<TYPES: NodeType> Inner<TYPES> { | |||
|
|||
return Ok(()); |
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.
If we don't return here we could get away without the outer loop I mentioned in my other comment. I also think we want to use an LruCache
for deduplication here just like in the LatestViewSyncCertificate
case
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.
Should we also consider actually having the cache a layer up? This way it can be shared for every task instead of just per task. The deduplication in this case was just so we don't pull multiple of the same latest proposal
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.
Not sure I understand what you mean by per task. If you mean the task we spawn to poll the webserver then yeah we should probably do a shared cache between the view number based and latest polls. On the other hand we could probably just get rid of the view based polling for proposals after this. I say we keep it as is for now
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.
Yeah, the cache is intra-task and not inter-task. I'll leave it for now
@rob-maron can you do this for |
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.
Fixes look good to me, lets get this into the release branch as well
crates/web_server/src/lib.rs
Outdated
@@ -33,21 +33,21 @@ struct WebServerState<KEY> { | |||
/// view number -> (secret, proposal) | |||
proposals: HashMap<u64, (String, Vec<u8>)>, | |||
/// for view sync: view number -> (relay, certificate) | |||
view_sync_proposals: HashMap<u64, Vec<(u64, Vec<u8>)>>, | |||
view_sync_certificates: HashMap<u64, Vec<(u64, Vec<u8>)>>, |
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: Since you are in I think it makes sense to use BTreeMap
s for these so we don't have to keep a variable for oldest and newest proposal/certificate
This PR:
For view sync certificates and quorum proposals:
This PR does not:
Fix the relay number check.
Key places to review:
web_server_network.rs