[BREAKING CHANGE] DefaultTracing: Removes DefaultTraceListener to disable tracing by default

[j82w]

Pull Request Template

Description

This PR is removing the DefaultTraceListener from the TraceSource by default unless there is a debugger attached. It is enabled by default for debugging scenario because performance is not an issue in those scenarios, and it can be helpful to root cause the issue being debugged.

The DefaultTraceListener adds a significant amount of overhead and will cause lock contention. There have been several live site incidents caused by this. This issue is more problematic for .NET Core because the app config file is not supported which make it difficult to disable it. For example, the performance project had to use reflection to get the trace source to remove it programmatically.

Type of change

Please delete options that are not relevant.

• [] Bug fix (non-breaking change which fixes an issue)
• [] New feature (non-breaking change which adds functionality)
• [] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [] This change requires a documentation update

Closing issues

To automatically close an issue: closes #IssueNumber

[sourabh1007]

It means, once it is enabled. Cx can run into same issue again. Do we know why DefaultTrace is causing the issue and can we solve it instead of putting it behind a flag?

[j82w]

It means, once it is enabled. Cx can run into same issue again. Do we know why DefaultTrace is causing the issue and can we solve it instead of putting it behind a flag?

The publicly documented recommendation is to not have trace enabled in production scenarios. There is no need for it. It's better to align the default with the recommendation. The DefaultTrace is part of the framework so we can't completely fix it. We have made several changes to reduce the number of traces to help with these scenarios.

[github-actions]

Please follow the required format: "[Internal] Category: (Adds|Fixes|Refactors|Removes) Description"

Internal should be used for PRs that have no customer impact. This flag is used to help generate the changelog to know which PRs should be included. Examples:
Diagnostics: Adds GetElapsedClientLatency to CosmosDiagnostics
PartitionKey: Fixes null reference when using default(PartitionKey)
[v4] Client Encryption: Refactors code to external project
[Internal] Query: Adds code generator for CosmosNumbers for easy additions in the future.

All good!

[ealsur]

Neat work!