{"action":"opened","issue":{"url":"https://api.github.com/repos/dotnet/corefx/issues/8511","repository_url":"https://api.github.com/repos/dotnet/corefx","labels_url":"https://api.github.com/repos/dotnet/corefx/issues/8511/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/corefx/issues/8511/comments","events_url":"https://api.github.com/repos/dotnet/corefx/issues/8511/events","html_url":"https://github.com/dotnet/corefx/issues/8511","id":154771890,"number":8511,"title":"Add the notion of metadata to DiagnosticsSource","user":{"login":"avanderhoorn","id":585619,"avatar_url":"https://avatars.githubusercontent.com/u/585619?v=3","gravatar_id":"","url":"https://api.github.com/users/avanderhoorn","html_url":"https://github.com/avanderhoorn","followers_url":"https://api.github.com/users/avanderhoorn/followers","following_url":"https://api.github.com/users/avanderhoorn/following{/other_user}","gists_url":"https://api.github.com/users/avanderhoorn/gists{/gist_id}","starred_url":"https://api.github.com/users/avanderhoorn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/avanderhoorn/subscriptions","organizations_url":"https://api.github.com/users/avanderhoorn/orgs","repos_url":"https://api.github.com/users/avanderhoorn/repos","events_url":"https://api.github.com/users/avanderhoorn/events{/privacy}","received_events_url":"https://api.github.com/users/avanderhoorn/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-05-13T18:20:44Z","updated_at":"2016-05-13T18:20:44Z","closed_at":null,"body":"DiagnosticsSource has been around for a while now and as more sites are instrumented and more listeners come online, it is becoming evident that there is a need for metadata to be provided as part of the system - specifically, the notion of collecting `timestamps`, `duration`, `correlationid` and possibly `stack`, `processid` and `threadid`. \r\n\r\nThese concerns are currently being tracked in an inconsistent manner across the publisher and subscriber code bases and has lead to several problems (i.e. different listeners coming up with different durations or timestamps, correlations not being determined correctly, listening to more events than are needed just to calculate duration, etc). Hence, after seeing issues like #8498 arise, it has been determined that the correct place isn't in the publisher or the subscriber, but most likely in the underlying subsystem - DiagnosticsSource.  \r\n\r\nThis issue is to track this discussion and determine the best way to start including this data into the system. Considerations that need to be had are as follows:\r\n- Can we get these updates in place before RTM/RTW lockdowns?\r\n- Can we make these changes in a non breaking way, given the fact that people are already taking a dependency on DS today?\r\n    - A possible solution here is to have two subscription methods which listeners can use, listen without metadata (what they would be using today) and listening with metadata. Other solutions are also possible.\r\n- Is there the need for the subscribers to dictate which metadata they would like collected (i.e. if no listeners want the stack, then the stack wouldn't be collected)?\r\n- Can the system be optimized so that to calculate durations, listener don't have to listen to both the `begin`/`end` events?\r\n- To do this work, do we need to take any extra dependencies, and if so does it matter?\r\n- Can correlations between `begin`/`end` events be provided in a deterministic way?\r\n\r\nObviously given where things are at timing wise with release schedules, we need to see what we think is the right solution and what we can get done in the time we have. Assuming this work is done, we can also go through and cleanup some of the publishers code and simply things greatly.\r\n\r\n// @vancem @stephentoub (note this should be assigned to @vancem for the time being)."}}