Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Messaging terminology: queue/topic vs address #3170

Closed
lmolkova opened this issue Feb 2, 2023 · 0 comments · Fixed by #3214
Closed

Messaging terminology: queue/topic vs address #3170

lmolkova opened this issue Feb 2, 2023 · 0 comments · Fixed by #3214
Assignees
Labels
area:semantic-conventions Related to semantic conventions semconv:messaging

Comments

@lmolkova
Copy link
Contributor

lmolkova commented Feb 2, 2023

#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.kind and messaging.source.kind

@lmolkova lmolkova changed the title Queue/topic terminology: use address Messaging terminology: queue/topic vs address Feb 2, 2023
@pyohannes pyohannes added area:semantic-conventions Related to semantic conventions semconv:messaging labels Feb 2, 2023
@pyohannes pyohannes assigned lmolkova and unassigned jmacd Mar 16, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:semantic-conventions Related to semantic conventions semconv:messaging
Projects
Status: V1 - Stable Semantics
3 participants