-
Notifications
You must be signed in to change notification settings - Fork 431
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
Add tests to confirm known deadlock issues #2199
Add tests to confirm known deadlock issues #2199
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2199 +/- ##
=======================================
- Coverage 79.2% 79.1% -0.2%
=======================================
Files 121 121
Lines 20964 21009 +45
=======================================
Hits 16620 16620
- Misses 4344 4389 +45 ☔ View full report in Codecov by Sentry. |
impl LogExporter for ReentrantLogExporter { | ||
async fn export(&mut self, _batch: LogBatch<'_>) -> LogResult<()> { | ||
// This will cause a deadlock as the export itself creates a log | ||
// while still within the lock of the SimpleLogProcessor. |
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.
wondering if we should bring the message queue back for simple log processor ?
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.
that might mitigate the issue temporarily, but we need to solve it via context based suppression I think.
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.
In context-based suppression, there may still be cases where we want to loop back the internal events at least once. This could potentially result in a deadlock situation.
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 follow that. Maybe add a unit test to cover the scenario, so its easy to track.
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 meant - even with the suppression logic in place, we may want the internal errors to loop-back to the pipeline once, hoping that the error is transient and doesn't cause infinite loop. In case of non-transient errors, the subsequent error is suppressed. But this can be something discussed when we look into suppression logic.
Not related to this, but moving to message queue will also fix hang issue - #2071 (comment)
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.
we may want the internal errors to loop-back to the pipeline once, hoping that the error is transient and doesn't cause infinite loop
Can you share a scenario where this is needed? I am not sure how often it is feasible for a component to determine if an error is transient or not.
Not related to this, but moving to message queue will also fix hang issue - #2071 (comment)
Yes, likely. But this needs a full redesign. I don't think adding a queue in the middle helps all cases.
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.
Thanks for the tests. nit comments, with the lint fix - should be good to merge.
Adding test to repro #1745