[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=62888#comment-62888 ] 

Ed Briggs commented on MQTT-234:
--------------------------------

I have three questions regarding this proposal.

In Peter's (very thorough) description, he has a note about the utility of have a notion of 'hard/soft' error messages. This is in his post in section 5. iii.

"iii) Nacks. This is a case where the hard/soft error thing might be useful. In the soft error case it might be handy to attempt to redeliver to another recipient, but we'd want to avoid the situation where the server sends it one at at time out to everyone only to get them nacked each time. Again this might be a case for giving the server some latitude"

In the current NAK proposal (MQTT-236) a NAK serves as a positive acknowledgment for the purposes of updating the unacknowledged message list.

Question 1:  Should we entertain special handling of NAKs which are returned to servers on a shared subscription?

In the current NAK proposal there is no distinction between hard and soft errors, which I will define as those errors which may be recoverable by re-sending or re-trying and those for which re-sending/re-trying is futile or would lead to retry cycles.

Question 2: Should we consider re-opening the topic of recoverable vs. non-recoverable errors? There is certainly benefit in making this distinction, but I fear that reaching consensus on which are/aren't recoverable may be difficult.

Finally, in the same post Section 2. b, Peter makes the distinction that shared subscriptions are 'owned' by the server, but non-shared subscriptions are owned by one or more session.

Question 3. Something about this distinction escapes me; is the purpose of server ownership to permit naming? I see both shared and un-shared subscriptions are destroyed when the reference count drops to zero. I feel I'm missing something here - probably obvious - and would be grateful for a nudge in the right direction.  Thank you.

> 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)