Simpler message acknowledgment for STOMP 1.2

[Lionel Cons]

In order to simplify message acknowledgment and address issue 46 [1], I
propose the following changes for STOMP 1.2:
* MESSAGE frames must contain an 'ack' header with an arbitrary value
* ACK/NACK frames must contain a matching 'id' header

Here are relevant spec snippets:
* MESSAGE frame:
| If the message is received from a subscription that requires explicit
| acknowledgment (either `client` or `client-individual` mode) then the
| `MESSAGE` frame MUST also contain an `ack` header with an arbitrary
| value. This header will be used to relate the message to a subsequent
| `ACK` or `NACK` frame.
* ACK frame:
| The `ACK` frame MUST include an `id` header matching the `ack` header
| of the `MESSAGE` being acknowledged. Optionally, a `transaction`
| header MAY be specified, indicating that the message acknowledgment
| SHOULD be part of the named transaction.

The change in functionality is minimal but it has several advantages:
- stop using the message-id for acknowledgment
- simpler MESSAGE/ACK matching using only one header
- similarity with the receipt mechanism

Comments?

Cheers,

Lionel

[1] https://github.com/stomp/stomp-spec/issues/46

[Chris Barrow]

Hi Lionel,

This is certainly workable, but I don't feel comfortable about it, for a
couple of reasons:

1. It's cluttering up the protocol. message-id header on ACK/NACK frame
is mandatory according to Stomp 1.1 spec so we're adding another
mandatory header which would typically be the same.
2. I realize there are issues about just how globally unique a
message-id should be. But I find it hard to believe there are cases
where it is not sufficiently unique for use in ACK/NACK. Do you know of
any such cases?

How about just firming up the rules for message-id sufficiently to allow
them to be used for ACK/NACK (but without going any further)? All that's
needed is to make sure message-id uniquely identifies each MESSAGE which
is sent to a client (that is, sent on a particular STOMP connection). If
message-id's can't even respect that requirement then I find it hard to
see what use they are at all. And STOMP intermediaries can always
transform them if needed.

Chris

[Hiram Chirino]

So part of the problem is message-id can be interpreted to mean 'the message-id assigned to the message when it was sent'.  Which means they expect it to remain the same when it is received even if sent to multiple subscribers on the same connection.  Consumers can use it to implement stuff like dup detection etc.  Lionel's solution avoids breaking that use case.

--

Hiram Chirino

Software Fellow | FuseSource Corp.

chi...@fusesource.com | fusesource.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo

[Lionel Cons]

Chris Barrow writes:
> 1. It's cluttering up the protocol. message-id header on ACK/NACK frame
> is mandatory according to Stomp 1.1 spec so we're adding another
> mandatory header which would typically be the same.

Not exactly the same. This is precisely the point.

As Rob pointed out in [1], there are two different uses of the message-id
header: to identify the message itself and to identify the delivery of that
message.

> 2. I realize there are issues about just how globally unique a
> message-id should be. But I find it hard to believe there are cases
> where it is not sufficiently unique for use in ACK/NACK. Do you know of
> any such cases?

Here is one: redelivery. A message is sent to a queue, received via a
subscription with client side ack, nack'ed and redelivered to the same
subscription (the exact behavior of nack is server specific). The client
would receive the same message twice, via the same subscription, with two
different deliveries.

Another example: Apollo. It does not change the user-supplied message-id so
if two messages are sent with the same id this can lead to ambiguities
during ack'ing.

IMHO, delivery (i.e. the MESSAGE/ACK exchange) is STOMP specific so it
should use STOMP specific headers and stay away from headers like message-id
that are used differently by different brokers.

Cheers,

Lionel

[1] https://groups.google.com/forum/#!topic/stomp-spec/DNM2mTw_G9E

[Chris Barrow]

I see, Lionel and Hiram, thanks for explaining. Would message-id still
be mandatory on ACK and NACK?

Chris

[Lionel Cons]

Chris Barrow writes:
> I see, Lionel and Hiram, thanks for explaining. Would message-id still
> be mandatory on ACK and NACK?

I would propose to keep it simple: no. STOMP 1.2 clients would only
need to set (N)ACK.id to be MESSAGE.ack, nothing more.

Cheers,

Lionel