-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[Release/7.0] Port EventCounters multi session support to 7.0 #84679
[Release/7.0] Port EventCounters multi session support to 7.0 #84679
Conversation
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.
approved. we will take for consideration in 7.0.x. please get a code review
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.
Same as the 6.0 PR. Behavior looks correct but ideally we'd not include the refactoring parts of the change that don't modify the final behavior.
@davmason - Reminder that you're free to merge your PR to the staging branch anytime, as long as:
If you want this fix to go into the June Release, please make sure to merge this before the code complete day (May 15th). |
c8e3d49
to
118a635
Compare
Rebasing against release/7.0-staging latest to trigger a new CI run |
Ports #82970 to 7.0
Customer Impact
Currently multiple different EventCounters sessions can be started but when any session stops we stop emitting counters for all events. This is true for dotnet-counters and manually enabling counters via in an process EventListener or via ETW/EventPipe/LTTNG.
We have quite a few internal and external teams using EventCounters, so as time goes on we find that they are disabling each other's sessions more and more. We have received requests from internal and external partners that this be fixed in servicing.
Testing
Partner team validation that it fixes their scenario.
Risk
This fix includes a minor breaking change as described in #84586. We previously would issue callbacks for EventSource Disable events before we fully marked the EventSource as disabled, but after we disallowed any further events from being sent. With this change we will issue callbacks after we mark the EventSource as fully disabled.
I cannot think of a scenario this would break, but it is different behavior and could theoretically cause issues for customers.