Messaging terminology: queue/topic vs address #3170
Assignees
Labels
Comments
lmolkova
changed the title
pyohannes
added
area:semantic-conventions
pyohannes
moved this from V1 - Stable Semantics
to In Progress
in Spec: Messaging Semantics
pyohannes
moved this from In Progress
to V1 - Stable Semantics
in Spec: Messaging Semantics
carlosalberto
pushed a commit
that referenced
this issue
Mar 21, 2023
… values (#3214) Fixes #3170, #3265, #3249 ## Changes ~~We currently allow `topic` or `queue` on `messaging.destination.kind`. While it's common in messaging world to have one or another, messaging semantic conventions can be applied to AMPQ communication (which does not have topic/queue terminology), [socket.io](https://socket.io/), and potentially other less traditional messaging use-cases.~~ It's unclear how `messaging.destination.kind` and `messaging.source.kind` could be used. The distinction between queue and topic is significant for messaging and distributed systems, but not for tracing. In either case, tracing backends should expect to process traces from 0+ messaging and 0+ messaging consumers. In either case, message consumers can be simultaneous or consequent and there could be many of them. The only known case (Solace) where it could be useful is when messaging system allows having queues and topic with the same name on the same broker, and it could be used to distinguish one from another. Based on messaging SIG discussion, the attributes are removed for the time being until we understand if and how they are useful. Depending on messaging system queues or topics behavior vary a lot and in future it would makes more sense to represent actual behavior with individual attributes such as: - auto-settlement (at-most-once or at least once guarantees) - settlement for individual messages or offsets - broadcast or unicast - etc
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this issue
Oct 31, 2024
… values (open-telemetry#3214) Fixes open-telemetry#3170, open-telemetry#3265, open-telemetry#3249 ## Changes ~~We currently allow `topic` or `queue` on `messaging.destination.kind`. While it's common in messaging world to have one or another, messaging semantic conventions can be applied to AMPQ communication (which does not have topic/queue terminology), [socket.io](https://socket.io/), and potentially other less traditional messaging use-cases.~~ It's unclear how `messaging.destination.kind` and `messaging.source.kind` could be used. The distinction between queue and topic is significant for messaging and distributed systems, but not for tracing. In either case, tracing backends should expect to process traces from 0+ messaging and 0+ messaging consumers. In either case, message consumers can be simultaneous or consequent and there could be many of them. The only known case (Solace) where it could be useful is when messaging system allows having queues and topic with the same name on the same broker, and it could be used to distinguish one from another. Based on messaging SIG discussion, the attributes are removed for the time being until we understand if and how they are useful. Depending on messaging system queues or topics behavior vary a lot and in future it would makes more sense to represent actual behavior with individual attributes such as: - auto-settlement (at-most-once or at least once guarantees) - settlement for individual messages or offsets - broadcast or unicast - etc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#2957 (comment)
AMQP does not use queue or topic terminology but operates with address (endpoint).
It might be possible to apply messaging conventions for socket.io operations where queue/topic don't work either.
Proposal from messaging SIG: allow custom values for
messaging.destination.kindandmessaging.source.kindThe text was updated successfully, but these errors were encountered: