Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.1
    • Component/s: core
    • Labels:
      None
    • Proposal:
      Hide

      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.

      Show
      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.

      Description

      (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.

        Attachments

          Activity

          Hide
          raphcohn Raphael Cohen (Inactive) added a comment -

          The key points were:-

          1 Clarify what store means and the fact that the server may purge / remove stuff as it sees fit.
          2 An administrator may purge storage at any time
          3 Elaborate minimal storage commitment for each QoS ?
          4 QoS 0 messages may disappear at any time
          5 Storage with respect to system outages / failures ?

          Proposal above covers 2, 3 and 4 and second-half of 1.

          First-half of 1 is covered when we describe store elsewhere IIRC.

          5 is tricky to define...

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - The key points were:- 1 Clarify what store means and the fact that the server may purge / remove stuff as it sees fit. 2 An administrator may purge storage at any time 3 Elaborate minimal storage commitment for each QoS ? 4 QoS 0 messages may disappear at any time 5 Storage with respect to system outages / failures ? Proposal above covers 2, 3 and 4 and second-half of 1. First-half of 1 is covered when we describe store elsewhere IIRC. 5 is tricky to define...
          Hide
          peterniblett Peter Niblett (Inactive) added a comment -

          Title should be broadened so that the subject of the issue includes QoS 0. Also the circustances in which QoS 0 get deleted might not be that rare

          Show
          peterniblett Peter Niblett (Inactive) added a comment - Title should be broadened so that the subject of the issue includes QoS 0. Also the circustances in which QoS 0 get deleted might not be that rare
          Hide
          raphcohn Raphael Cohen (Inactive) added a comment -

          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.

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - 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.
          Hide
          ragupta2 Rahul Gupta (Inactive) added a comment -

          fixed in WD-14

          Show
          ragupta2 Rahul Gupta (Inactive) added a comment - fixed in WD-14
          Hide
          ragupta2 Rahul Gupta (Inactive) added a comment -

          This issue to be further discussed, I realized that proposal was still not approved in TC

          Show
          ragupta2 Rahul Gupta (Inactive) added a comment - This issue to be further discussed, I realized that proposal was still not approved in TC
          Hide
          coppen Richard Coppen (Inactive) added a comment -

          moved to resolved in error

          Show
          coppen Richard Coppen (Inactive) added a comment - moved to resolved in error
          Hide
          coppen Richard Coppen (Inactive) added a comment -

          Duplicate of 70, 70 fixes in WD17

          Show
          coppen Richard Coppen (Inactive) added a comment - Duplicate of 70, 70 fixes in WD17
          Hide
          coppen Richard Coppen (Inactive) added a comment -

          see storing state 4.1 in WD17

          Show
          coppen Richard Coppen (Inactive) added a comment - see storing state 4.1 in WD17

            People

            • Assignee:
              ragupta2 Rahul Gupta (Inactive)
              Reporter:
              raphcohn Raphael Cohen (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: