Skip to content
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.

Sign up for GitHub

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

Jump to bottom

sc_network::NetworkWorker::event_streams should be a bounded channel #557

Open
tomaka opened this issue Apr 7, 2020 · 4 comments
Open

sc_network::NetworkWorker::event_streams should be a bounded channel #557

tomaka opened this issue Apr 7, 2020 · 4 comments
Labels
D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase.

Comments

@tomaka
Copy link
Contributor

tomaka commented Apr 7, 2020

Right now if for example a sc_network_gossip::GossipEngine doesn't process notifications quickly enough, we will continue buffering notifications forever in its events stream.

Instead, we should considering limiting the events stream to a certain size. If the channel is full, we would freeze the network worker itself, with a certain timeout after which the events stream is dropped and an error printed in the logs.

The first step to do so would be to turn impl Future for NetworkWorker into an async method.
@tomaka tomaka mentioned this issue Apr 9, 2020
Merged
@tomaka
Copy link
Contributor Author

tomaka commented Apr 9, 2020 •
edited
Loading

The tokio::sync::broadcast module has a different approach. Sending events is never blocking nor bounded, but events are dropped if the queue is full. The receiver is informed if events are dropped.

@tomaka tomaka mentioned this issue Apr 20, 2020
Closed
@tomaka
Copy link
Contributor Author

tomaka commented Jul 29, 2020

Relates to #554

@stale
Copy link

stale bot commented Jul 7, 2021

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the A5-stale label Jul 7, 2021
@tomaka
Copy link
Contributor Author

tomaka commented Jul 8, 2021

Issue still relevant and important.

@stale stale bot removed the A5-stale label Jul 8, 2021
@altonen altonen transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase. and removed U3-nice_to_have labels Aug 25, 2023
helin6 pushed a commit to boolnetwork/polkadot-sdk that referenced this issue Feb 5, 2024
@yjhmelody @sorpaas
chore: minor improve for rpc (paritytech#557)
3366a1d 
* chore: minor improve for rpc

* Fix libsecp256k1 crate name reference

Co-authored-by: Wei Tang <wei@that.world>
Co-authored-by: Wei Tang <accounts@that.world>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
D2-substantial Can be fixed by an experienced coder with a working knowledge of the codebase.
Projects
Networking
Status: Backlog 🗒
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tomaka @altonen @the-right-joyce