Messaging: clarify definitions of queue and topic #3265
Assignees
Labels
Comments
lmolkova
added
area:semantic-conventions
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
|
closed in #3214 with open-telemetry/semantic-conventions#1220 to track any-future work |
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
The spec creates a wrong impression that queues provide exactly once guarantees which is not the case
Popular queues provide at least once guarantees along with at-most once, which is configurable with auto-settlement.
Proofs:
Message can be delivered multiple times if it's not settled during delivery (ack not received, settlelment call times out, etc). Some queues allow to defer/re-publish message at settlement (RabbitMQ, Azure ServiceBus)
Originally posted by @lmolkova in #3214 (comment)
The text was updated successfully, but these errors were encountered: