-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Network::Connection: Add L4 crash dumping support #14509
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
Changes from 4 commits
1bd6d98
60dc8a6
63bbc55
056c07a
a85e8c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,16 +7,19 @@ | |
| namespace Envoy { | ||
|
|
||
| /* | ||
| * A class for tracking the scope of work. | ||
| * Currently this is only used for best-effort tracking the L7 stream doing | ||
| * work if a fatal error occurs. | ||
| * An interface for tracking the scope of work. Implementors of this interface | ||
| * can be registered to the dispatcher when they're active on the stack. If a | ||
| * fatal error occurs while they were active, the dumpState method will be | ||
| * called. | ||
| * | ||
| * Currently this is only used for the L4 network connection and L7 stream. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. class ScopeTrackedObject : public Dumpable {} But are the two interfaces really needed? Why is it important to distinguish between objects that can be registered and ones that simply have a dump method?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The intent is to decrease cognitive load and have it be more explicit than implicit i.e. why is If we enforce this via the type system, the intent is a bit more clear instead of "maybe they forgot to register Thoughts?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is not being able to register the object useful? Having 2 interfaces that are so similar adds to cognitive load.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I would tend to agree that the two interfaces do not feel that useful to me, but I don't feel strongly about it. At minimum I would derive from the other class as @antoniovicente suggests.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair point, will just go with |
||
| */ | ||
| class ScopeTrackedObject { | ||
| public: | ||
| virtual ~ScopeTrackedObject() = default; | ||
|
|
||
| /** | ||
| * Dump debug state of the object in question to the provided ostream | ||
| * Dump debug state of the object in question to the provided ostream. | ||
| * | ||
| * This is called on Envoy fatal errors, so should do minimal memory allocation. | ||
| * | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.