[OASIS Issue Tracker] Commented: (MQTT-19) How Retained publications are deleted.

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

    [ http://tools.oasis-open.org/issues/browse/MQTT-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33602#action_33602 ] 

Raphael Cohen commented on MQTT-19:
-----------------------------------

Trying to address (2):-

This is not necessarily an administrator permission, but it is an important consideration. If a broker wants to implement permissions here, then it's highly likely that the same permission to retain a message (with all the potential for blowing up because there are too many) is the same that would be used for removing it... Perhaps the way forward here is to use 'SHOULD'. In an ideal world, with no existing spec and implementations, I'd actually argue for a special command flow so things were unambiguous, but that's not possible

Are we also going to clarify / enforce that a deleting message MUST also have the RETAIN flag set? It would seem prudent. That would allow differentiation of empty (do not delete) and empty (delete). Are we also going to suggest that it is *not* an error to try to delete a subscription that does not exist? (very important for recovery in a 'did I or didn't I situation'), ie it's idempotent.

If we have retained message creation via the protocol, I think it's essential to have deletion via the protocol. There's no way any modern broker admin is going to want to have occasionally query and remove retained messages, especially when its the clients of the broker that have the domain knowledge, not the broker.


Discussing (1):-

If we take the approach above - making use of the RETAIN flag be required for deletion to differentiate - then I think we can mitigate this problem.


Observations on (3):-

I agree we should say very little about broker behaviour, but this is one place where have to say something, as it substantially affects client expectations.

Messages are sent and delivered in order. If one is replicating to a server cluster, or bridging to another broker, then the command flow should be serialised and replayed - this is how most forms of replication work, for instance. Any broker worth its salt will, at the very least, know about message receipt order. There is always the possibility that the order of a retain create and a retain delete is permuted because a client is using two connections to send one or the other separated by a short amount of time. Such a race condition is always the client's responsibility - it is no different to any other abuse of message queue total ordering. of course, if it is accidental, then the client can mitigate by using the same client identifier and rely on a broker that implements connection stealing (last connection on that id wins - many brokers do this to allow client failover when one can't be 100% the other client is genuinely dead).



> How Retained publications are deleted.
> --------------------------------------
>
>                 Key: MQTT-19
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-19
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>            Reporter: Andrew Banks
>
> There specification suggests that a retained message published with a zero byte payload can be used to cause a retained message to be deleted by the server, although it
> leaves this behavior as optional. It is not clear whether the zero length message should be sent to subscribers.

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