-
Notifications
You must be signed in to change notification settings - Fork 29
Subscribe and messagedata
This page describes the behavior of the Subscribe(...) method in some detail.
There are two different behaviors exhibited by Subscribe(...) depending on the connection's Stomp protocol level.
Note that the Stomp 1.1+ specifications require a unique id to be assigned to each subscription. See for example Stomp 1.1 Subscribe. Users of the stompngo package SHOULD supply a unique id header when Subscribe is called. However, the package does allow callers to not supply this ID under the following conditions.
If the caller does supply a subscription id, that id is used. The MessageData channel returned is a subscription unique channel, based on the id. The supplied id MUST be unique to the session.
If the caller does not supply a subscription id, one is not used. The MessageData channel returned is the shared connection level stompngo.Connection.MessageData channel. Note: this can cause coordination difficulties for Stomp 1.0 clients using multiple subscriptions concurrently. The client is responsible for any coordination required.
If the caller does supply a subscription id, that id is used. The MessageData channel returned is a subscription unique channel, based on the id. The supplied id MUST be unique to the session.
If the caller does not supply a subscription id, an id is generated by the package. The MessageData channel returned is a subscription unique channel, based on the id. Because Stomp 1.1 requires this id to also be used when calling Unsubscribe, it is the client's responsibility to determine the id from subsequent message traffic.
For a Stomp 1.1+ connection, the unique subscription id in use for the destination MUST be used when Unsubscribe for the destination is called.
Receipts are never received on a subscription unique MessageData channel. They are always queued to the shared connection level stompngo.Connection.MessageData channel. The reason for this behavior is because RECEIPT frames do not contain a subscription Header (per the STOMP specifications).
Errors are never received on a subscription unique MessageData channel. They are always queued to the shared connection level stompngo.Connection.MessageData channel. The reason for this behavior is because ERROR frames do not contain a subscription Header (per the STOMP specifications).