[OASIS Issue Tracker] (MQTT-234) Shared Subscriptions

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62889#comment-62889 ] 

Ken Borgendale commented on MQTT-234:
-------------------------------------

Ed:
Question 1: The server should schedule redelivery of a message if it has not received an ACK (or NAK) depending on the QoS at which it is sent.  I believe that the statement that a NAK finalizes the message flow is as correct for shared subscriptions as for non-shared subscriptions.

Question 2: If we have a need for recoverable vs non-recoverable errors it should be orthogonal to shared subscriptions.  I suggest that we proceed to try to complete the current NAK JIRA, and raise this as a subsequent issue, but only if we find a use case where it is important. 

Question 3: Subscription ownership.  Saying the shared subscription is owned by the server is perhaps not quite correct.  It is more like a shared ownership which goes away only when there are zero sessions which share the subscription.  Thus such a subscription is not owned by the session which created the subscription.  A common implementation is a virtual session which is never associated with a connection.  As this virtual session is created by the server, you can say that the server owns the subscription.

> Shared Subscriptions
> --------------------
>
>                 Key: MQTT-234
>                 URL: https://issues.oasis-open.org/browse/MQTT-234
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: futures
>    Affects Versions: 5
>            Reporter: Andrew Banks
>            Priority: Critical
>
> Shared Subscriptions
> --------------------
> Shared subscriptions allow a set of clients to share the consumption of messages
> produced in response to a subscription. The set of subscribers is created by the use
> of a common share name. Shared subscriptions provide a facility similar to point to 
> point messaging in that the processing of messages is not limited to the availability 
> or capacity of a single consumer, the share name is analogous to the queue name in 
> that it names the list of messages to be processed.
> I suggest that a shared subscription be defined by the topic filter syntax:
>   $share:shareName:topicFilter
> - This specialised topic filter takes the place of the normal topic filter in the 
>   subscribe packet. 
> - The "$share:" prefix uses a reserved $ name and will therefore not cause a conflict
>   with other topic filters.
> - shareName is a string which labels the shared subscription and must not contain any 
>   ":" characters.
> - TopicFilter follows the existing topic filter rules.
> - Subscribing clients will be a member of the share only if both the shareName and
>   topicFilter are identical. So, a different shareName with the same topicFiler 
>   will create a different share. Similarly a shareName followed by a different topic
>   filter will create separate share.
> - Servers may decline to support shared subscriptions by not accepting subscribe
>   packets containing topic filters starting with the "$share:" prefix. However, if 
>   they do accept the "$share:" prefix they must follow this definition.
> - The subscribing clients may make both non durable and durable subscriptions by 
>   setting clean session true or false. The shared subscription ceases to exist if    
>   the number of clients subscribed to it reaches zero. If the shared subscription
>   ceases to exist the messages queued for processing are deleted by the server as 
>   with an non shared subscription.
> - A good server implementation will avoid allocating messages to subscribers with 
>   durable subscriptions while the client is disconnected. Instead the messages will be 
>   allocated when a suitable client connects. 
> - A Qos=1 message should be reallocated to another client sharing the same subscription
>   if the network connection to the client is lost before the PUBACK is received.
>   Qos=0 and Qos=2 messages must not be reallocated. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)