Skip to content
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

EventHubsDiagnosticSource does not follow corefx DiagnosticSource recommendations #7173

Closed
gambrose opened this issue Sep 21, 2018 · 6 comments
Assignees
Labels
Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. Event Hubs Service Attention Workflow: This issue is responsible by Azure service team.
Milestone

Comments

@gambrose
Copy link

EventHubsDiagnosticSource exposes events named like Microsoft.Azure.EventHubs.Receive.Stop which goes against recommendations to not include the Listener name in the event name.

@serkantkaraca
Copy link
Member

@TomMilos > Can you help on the comment?

@serkantkaraca
Copy link
Member

Are you referring to this?

"DO - keep the names reasonably short (< 16 characters). Keep in mind that event names are already qualified by the Listener so the name only needs to be unique within a listener. Short names make IsEnabled() faster."

@gambrose
Copy link
Author

gambrose commented Oct 5, 2018

Yes I was, the event names should not be qualified with Microsoft.Azure.EventHubs.

I also think it may be worth considering splitting out Receive and Send as two distinct DiagnosticListeners as the recommendations say this should be considered as they are kind of two distinct use cases.

@serkantkaraca
Copy link
Member

I will take a look once I have some time. Thx for pointing.

@serkantkaraca serkantkaraca transferred this issue from Azure/azure-event-hubs-dotnet Aug 6, 2019
@triage-new-issues triage-new-issues bot added the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Aug 6, 2019
@loarabia loarabia added Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. Event Hubs Service Attention Workflow: This issue is responsible by Azure service team. labels Aug 6, 2019
@triage-new-issues triage-new-issues bot removed needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. labels Aug 6, 2019
@serkantkaraca
Copy link
Member

PR - #7186

@serkantkaraca serkantkaraca self-assigned this Aug 7, 2019
@Azure Azure deleted a comment Aug 7, 2019
@Azure Azure deleted a comment Aug 7, 2019
@jfggdl jfggdl modified the milestones: Sprint 157, Sprint 158 Aug 12, 2019
@jfggdl
Copy link

jfggdl commented Aug 12, 2019

The PR has been merged. We are expecting its imminent release in September.

@jfggdl jfggdl closed this as completed Aug 12, 2019
openapi-bot-sh-dev bot pushed a commit to test-repo-tih/azure-sdk-for-net that referenced this issue Oct 8, 2019
Update examples (Azure#7429)

* Copy compute.json and runCommands.json from 2019-03-01 to 2019-07-01

* changes to add publicIpAddressVersion field (Azure#7173)

* Add diskEncryptionSet in swagger compute-2019-07

* resolve semantic conflicts

* Fix model conflicts

* Resolve readme

* Resolve readme

* Resolve description conflicts

* Improve description

* Fix spell error

* Add some examples.

* fix model error

* Update examples
@github-actions github-actions bot locked and limited conversation to collaborators Mar 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. Event Hubs Service Attention Workflow: This issue is responsible by Azure service team.
Projects
None yet
Development

No branches or pull requests

4 participants