[rabbitmq-discuss] [rabbitmq-stomp] Is the use of receipt header for SUBSCRIBE still recommended?
matthias at rabbitmq.com
Sun Jan 26 11:17:55 GMT 2014
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.
More information about the rabbitmq-discuss