[rabbitmq-discuss] [rabbitmq-stomp] Is the use of receipt header for SUBSCRIBE still recommended?

[Matthias Radestock]

On 26/01/14 09:53, Michael Justin wrote:
> On 24.01.2014 12:52, Emile Joubert wrote:
>> On 24/01/14 11:18, Michael Justin wrote:
>>
>>> Has there been a change in the RabbitMQ STOMP plug-in since, which makes
>>> this workaround obsolete, or is it still recommended to use a receipt?
>>
>> There have been numerous improvements to the STOMP adapter since v2.4.0,
>> but SUBSCRIBE remains an asynchronous operation. As Rob suggested,
>> requiring a receipt makes it a synchronous operation. If your
>> application requires confirmation that the subscription is in place then
>> you need the synchronous version.
>
> thank you for the information! The synchronous solution using a receipt
> header works very well, good to know that it is unchanged, so my app
> (client library) docs are still valid and up-to-date.

There is actually no other way it could work. i.e. if you issue a 
SUBSCRIBE on one connection and then a SEND on another, in the absence 
of an acknowledgement from the server - which is what the RECEIPT header 
provides - then those two commands will simply race each other, leading 
to a non-deterministic outcome.

Now, if the SUBSCRIBE and SEND were issued on the *same* connection then 
I'd expect no such race, i.e. the SEND should only be processed after 
the SUBSCRIBE and thus if the subscription matches the sent message then 
the subscriber should receive that.

Matthias.