Initial proposal #1
Conversation
| created, it’s no longer permissible to edit the bare message. So if it were | ||
| necessary to annotate the message inside the middleware as it transits, that | ||
| MUST happen in the “message-annotations” section, using the |
There was a problem hiding this comment.
Comment was resolved in original PR:
| truncating or reusing some fields. | ||
|
|
||
| ## Batching |
There was a problem hiding this comment.
Comment for original PR:
| AMQP defines message as a payload with the additional annotations sections. | ||
| There are two annotation sections this specification refers - | ||
| "application-properties" and "message-annotations". See |
There was a problem hiding this comment.
Comment from original PR:
| of AMQP specification. | ||
|
|
||
| Property name MUST be `traceparent` - all lowercase without delimiters. |
There was a problem hiding this comment.
from: @calohmn
Considering the case that the traceparent and tracestate fields are transported via message-annotations:
As for the base type of the message-annotations, the AMQP spec says (http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations):
The annotations type is a map where the keys are restricted to be of type symbol or of type ulong. All ulong keys, and all symbolic keys except those beginning with "x-" are reserved. Keys beginning with "x-opt-" MUST be ignored if not understood. On receiving an annotation key which is not understood, and which does not begin with "x-opt", the receiving AMQP container MUST detach the link with a not-implemented error.
Concerning the names of message-annotations:
A registry of defined annotations and their meanings is maintained [AMQPMESSANN].
The question here: Are the names of the traceparent and tracestate fields supposed to be somehow registered as reserved with OASIS. Otherwise it looks to me as if the prefix "x-opt-" should be used.
There was a problem hiding this comment.
Also created this issue: #2
There was a problem hiding this comment.
As I wrote in the issue, we can register this fields in AMQP TC
| See definition of type map in section | ||
| [1.6.23](http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#type-map) | ||
| of AMQP specification. |
There was a problem hiding this comment.
Comment from @calohmn
Considering the case that the traceparent and tracestate fields are transported via application-properties:
About application-properties, the AMQP spec says (http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-application-properties):
The keys of this map are restricted to be of type string (which excludes the possibility of a null key) and the values are restricted to be of simple types only, that is, excluding map, list, and array types.
This looks incompatible with wanting to store a tracestate AMQP map in there.
There was a problem hiding this comment.
HTTP headers are constrained to strings and you still manage to put a map there.
There was a problem hiding this comment.
I was referring to the AMQP map datatype being mentioned for the tracestate field value here.
As for using a string value instead, I guess it should be clarified then, how exactly the string-to-string map is to be encoded in that string value.
There was a problem hiding this comment.
it is impractical to ask everyone to parse tracestate - the majority of services will blindly propagate it:
- receive incoming http request with tracestate as string
- put tracestate into EventHub message. If it is a map - it will require parsing it in the first place which should not be necessary for arbitrary service
So my proposal: it should be either a string (exactly like http-header) or byte array to save n message size (and this spec should define how it is formatted).
|
|
||
| Strings duplicating the size of a field, using list of binaries will require to | ||
| redefine the way the field serialized, parsed, and versioned. So re-using binary | ||
| protocol looks like a logical solution. |
There was a problem hiding this comment.
Comment from original PR:
| such problems. | ||
|
|
||
| TODO: do we need to define a way to specify trace context of read operation? Is |
There was a problem hiding this comment.
I'm not sure what you're referring to here. If there's an error in delivering the message (delivery state "rejected"), that state includes an error object and that can carry an extra "info" map, which could conceivably carry trace objects.
Co-Authored-By: SergeyKanzhelev <[email protected]>
|
I'll merge this proposal and will file issues from the comments |
This PR was moved from w3c/trace-context#217
CC: @lmolkova @clemensv @calohmn @AloisReitbauer @yurishkuro @grs
I'm moving comments from original PR as well