OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (MQTT-79) Allow deletion of QoS1/2 messages in rare circumstances


     [ http://tools.oasis-open.org/issues/browse/MQTT-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raphael Cohen updated MQTT-79:
------------------------------

    Proposal: 
3.1.2.3.1 Clean Session, Page 19, Line: 559 Replace para starting "State could be lost" with:-

In exceptional circumstances, the client or server MAY delete session state, or QoS 1 and 2 messages, at any time if required to do so because of:-
* resource constraints;
* limitations of the storage mechanism used;
* partial or complete corruption of the storage mechanism;
* administrative action, or
* on becoming aware of external knowledge that a message or messages can no longer be delivered to any current or future client.

Furthermore, a client or server MAY delete QoS 0 messages at any time for the same conditions as bulleted in the preceding list.

This could result in the loss or duplication of messages regardless of the QoS used. 


Non-normative comment
The exceptional circumstances exist to cover that which can not be overcome. Implementations should make all possible efforts to preserve QoS 1 and 2 messages such that in practice their delivery guarantees are met during normal operation. The intent of this exemption is to accommodate scenarios such as:-

* the wear-levelling failures of solid-state storage
* the exhaustion of storage
* quota restrictions to prevent Denial of Service attacks
* unavoidable disk failure
* clients using the service being retired from service so their messages are no longer of value
* hard system failures, eg due to data centre power failure

For QoS 0 messages, the constraint is there to make it clear that QoS messages are ephemeral with no guarantees of delivery or even visibility within the client or server.

As a consequence of these constraints, implementors should be aware that loss or duplication of messages is possible regardless of the QoS used and should program their systems to be idempotent to this possibility.


Added proposal to take to TC 10/Oct/2013 accommodating Peter's suggestion of a broader reference. I'd have liked to get it all into the one MAY, but it results in so many clauses that the scope of the first sentence is ambiguous.

> Allow deletion of QoS1/2 messages in rare circumstances
> -------------------------------------------------------
>
>                 Key: MQTT-79
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-79
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Raphael Cohen
>             Fix For: 3.1.1
>
>
> (Reference MQTT-7).
> After " the client and server MUST store qos 1 and qos 2 messages, including those new messages due to active subscriptions on the server ", insert:-
> The server MAY then delete such messages at any time if required to do so because of resource constraints, administrative action or becoming aware of external knowledge that the message can no longer be delivered to any current or future client.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]