-
Notifications
You must be signed in to change notification settings - Fork 54
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
Fix tedge-agent stuck on too many pending operations #2640
Fix tedge-agent stuck on too many pending operations #2640
Conversation
Robot Results
|
e1c7000
to
b9e3d85
Compare
2fffde2
to
fb0b85e
Compare
Codecov ReportAttention:
Additional details and impacted files
|
b94312b
to
11ac977
Compare
pub(crate) input_receiver: LoggingReceiver<AgentInput>, | ||
pub(crate) input_receiver: UnboundedLoggingReceiver<AgentInput>, |
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.
An alternative to fix the issue could be to use two receivers.
- One receiver to receive progress feedback from the software actor
- Another to collect requests from MQTT
Using a biased select, one can then give the priority to the feedback messages.
11ac977
to
f96fb86
Compare
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.
LGTM
Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
At least one such receiver should be used when there is a loop of actors, say A sending data to B and B sending data to A. Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
The tedge_operation_converter is sending messages to the software_manager actor, while receiving messages from this same actor. This leads to a deadlock if one their message boxes start to be full. This is notably the case on startup if there are too many pending operations awaiting over MQTT to be processed. With the tedge_operation_converter using an unbounded receiver, all these messages can be consumed without blocking status messages received from the software_manager actor. Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
f96fb86
to
862357a
Compare
Proposed changes
Introduce unbounded receivers. Given a cycle of actors (say A sending messages to B, B to C and C to A), at least one of these actors must use such an unbounded receiver.
Types of changes
Paste Link to the issue
#2639
Checklist
cargo fmt
as mentioned in CODING_GUIDELINEScargo clippy
as mentioned in CODING_GUIDELINESFurther comments