This repository was archived by the owner on Nov 20, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 191
Adding a feature to get the traceidentifier for a request #210
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
18 changes: 18 additions & 0 deletions
18
src/Microsoft.AspNet.Http.Interfaces/IRequestIdentifierFeature.cs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved. | ||
// Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information. | ||
|
||
using System; | ||
|
||
namespace Microsoft.AspNet.Http.Interfaces | ||
{ | ||
/// <summary> | ||
/// Feature to identify a request. | ||
/// </summary> | ||
public interface IRequestIdentifierFeature | ||
{ | ||
/// <summary> | ||
/// Identifier to trace a request. | ||
/// </summary> | ||
Guid TraceIdentifier { get; } | ||
} | ||
} |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Any reason this is specifically a Guid and not a string? (The OWIN spec doesn't specify a format.)
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.
BTW I'm not suggesting it should be a string, just asking.
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.
Traditionally these have been GUIDs so that they can be flowed via the CorrelationManager.
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.
Yeah that makes sense... but not really 😄 I'm not really opposed to it being a GUID, it just seems so arbitrary (even in CorrelationManager). I mean what's so special about GUIDs anyway - a correlation id is logically an opaque value. So honestly I'm fine either way.
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.
GUIDs actually solve the problem nicely because they have a definite ordering so can be indexed. You can't do that with strings without a lot of ceremony: making sure everything is length-prefixed in storage (nvarchar, but then you kill indexability), making sure everybody agrees on which comparer to use (good luck doing this in SQL), and so on.
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.
That they have a fixed, unambiguous, universal representation is a huge plus over strings, even if ordering doesn't matter. I agree that academically the difference shouldn't matter, but practically it does. I guarantee you'll have a difficult time building a reliable, high-performance correlation engine if your key is an arbitrary structureless string.
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.
Most of the time these Ids are persisted as a string always so I'm not sure what you mean. Are you saying if we don't use the .NET Guid type that it won the performant?
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.
The nearly 100% use case is that they're persisted in an ETW log or similar structure, so they're definitely not persisted as strings. Please reread my argument above - I'm not advocating GUIDs for the sake of having GUIDs, I'm advocating it because it's structured, unambiguous, and easy for correlation engines to reason about. If you have another structure in mind that meets these requirements then by all means suggest it.
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.
@Eilon - Just as a side note.
OWIN
spec actually saysowin.RequestId
is astring
.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.
Yep I read the OWIN spec 😄 Honestly I'm OK with forcing GUID because there's nothing really wrong with it in practice. It's just kind of annoying when practicality trumps so-called "correctness."