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
Parallelize processing of incoming gossip messages #2463
Conversation
Add param to limit degree of concurrency Add timeout to syncer
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.
nice cleanup
Clean up and improve tests, resolve merge conflicts
bors merge |
## Motivation Fixes an issue spotted in tn132: processing an inbound block may take a very long time (> 1m), during which time all other inbound blocks (messages on the same gossip channel) are blocking ## Changes - Adds concurrency to processing of inbound gossip messages (per protocol/channel), with a limit on the degree of concurrency - Add timeout to syncer layer fetch ## Test Plan Includes regression tests ## TODO <!-- This section should be removed when all items are complete --> - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [ ] Update documentation as needed ## DevOps Notes <!-- Please uncheck these items as applicable to make DevOps aware of changes that may affect releases --> - [x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources) - [x] This PR does not affect public APIs - [x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.) - [x] This PR does not make changes to log messages (which monitoring infrastructure may rely on) Co-authored-by: Dmitry Shulyak <yashulyak@gmail.com>
Build failed: |
bors merge |
## Motivation Fixes an issue spotted in tn132: processing an inbound block may take a very long time (> 1m), during which time all other inbound blocks (messages on the same gossip channel) are blocking ## Changes - Adds concurrency to processing of inbound gossip messages (per protocol/channel), with a limit on the degree of concurrency - Add timeout to syncer layer fetch ## Test Plan Includes regression tests ## TODO <!-- This section should be removed when all items are complete --> - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [ ] Update documentation as needed ## DevOps Notes <!-- Please uncheck these items as applicable to make DevOps aware of changes that may affect releases --> - [x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources) - [x] This PR does not affect public APIs - [x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.) - [x] This PR does not make changes to log messages (which monitoring infrastructure may rely on) Co-authored-by: Dmitry Shulyak <yashulyak@gmail.com>
Build failed: |
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.
latenodes doesn't fail so often in develop. please no need to retry until it succeeds
# Conflicts: # cmd/node/node.go # docker-compose.yml # layerfetcher/layers.go # p2p/service/gossip_listener.go # syncer/syncer.go # syncer/syncer_test.go
bors merge |
👎 Rejected by code reviews |
bors merge |
👎 Rejected by code reviews |
bors try |
tryBuild failed: |
bors try |
tryBuild failed: |
late-nodes still fails |
@nkryuchkov what is the point of merging this? this code is replaced in my change |
Will be overridden by #2801 |
Motivation
Fixes an issue spotted in tn132: processing an inbound block may take a very long time (> 1m), during which time all other inbound blocks (messages on the same gossip channel) are blocking
Changes
Test Plan
Includes regression tests
TODO
DevOps Notes