Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[Merged by Bors] - serve malfeasance proof over grpc #4851
[Merged by Bors] - serve malfeasance proof over grpc #4851
Changes from 4 commits
f3bbedb
957e842
be46bac
3c0113f
0c23579
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning on line 62 in api/grpcserver/activation_service.go
Codecov / codecov/patch
api/grpcserver/activation_service.go#L56-L62
Check warning on line 622 in api/grpcserver/mesh_service.go
Codecov / codecov/patch
api/grpcserver/mesh_service.go#L621-L622
Check warning on line 627 in api/grpcserver/mesh_service.go
Codecov / codecov/patch
api/grpcserver/mesh_service.go#L626-L627
Check warning on line 637 in api/grpcserver/mesh_service.go
Codecov / codecov/patch
api/grpcserver/mesh_service.go#L636-L637
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 (and unrelated to this PR):
I don't think it makes sense to have
eventch
andfullch
as return value inconsumeEvents
if the buffer ineventch
runs full, the listener doesn't read from it. Why should the listener read fromfullch
?The buffer is also huge -> 32768 events. So if
fullch
is closed the listener hasn't read events for quite some time.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 see this more as a safeguard to stopgap a programming error from OOM e.g. doing something blocking when processing an event. not sure about the history here.
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.
Hm... I am not sure if we are doing it correctly. I see 2 possible approaches:
Both approaches can give some leeway to busy consumers by using buffered channels. Here it looks like the first approach was taken (if the consumer isn't listening eventually the producer will stop sending). Just that the consumer will also not handle the events any more that were buffered for it when it becomes ready again. Additionally his happens not immediately: the channels are read in the same select statement, so some events might still be processed before the consumer gets the message that no events will be coming any more and stops reading from
eventch
.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.
other stream APIs are implemented this way as well. if you feel strongly about changing the behavior, maybe file an issue for what you want to fix?
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.
the idea is that stream subscriber should never be able to block consensus code and we shouldn't silently drop events either. so once we see that subscriber is not reading fast enough error is returned from api and channel is unregistered
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.
Yes, I understand. I think there is an issue on the consumer side with this approach where overflows of the
eventch
are not handled deterministically:Both
eventch
andfullch
are always read from in the sameselect
statement (not just here). Iffullch
is closed the cosumer might read anything between 0 to 10 more events (more than 10 become extremely unlikely) fromeventch
before they actually stop processing events.Check warning on line 641 in api/grpcserver/mesh_service.go
Codecov / codecov/patch
api/grpcserver/mesh_service.go#L640-L641
Check warning on line 647 in api/grpcserver/mesh_service.go
Codecov / codecov/patch
api/grpcserver/mesh_service.go#L646-L647
Check warning on line 656 in api/grpcserver/mesh_service.go
Codecov / codecov/patch
api/grpcserver/mesh_service.go#L654-L656
Check warning on line 663 in api/grpcserver/mesh_service.go
Codecov / codecov/patch
api/grpcserver/mesh_service.go#L662-L663
Check warning on line 669 in api/grpcserver/mesh_service.go
Codecov / codecov/patch
api/grpcserver/mesh_service.go#L668-L669