[rabbitmq-discuss] STOMP and transactions

Fri Aug 20 18:59:02 BST 2010

Göran,

What sorts of problems did you have getting RabbitMQ up and running,
that we could address?

alexis

2010/8/20 Göran Krampe <goran at krampe.se>:
> Hej!
>
> On 08/20/2010 06:55 PM, Tony Garnock-Jones wrote:
>>
>> Hej Göran,
>
> Swedish! :)
>
>> I spotted your library over on squeak-dev - very cool. I'm pleased you're
>> trying it out against RabbitMQ.
>
> Hehe, yeah, I started with CoilMQ but I realized it doesn't even do
> receipts. I must say that getting Rabbit up and running was NOT trivial. You
> guys need to put out a Howto for that.
>
> But disregarding that, Rabbit seems nice. And yeah, I noticed your AMQP lib
> on SS, and funny enough searching for "STOMP" gives a hit on your private
> repo I think ;)
>
>> Transactions in AMQP (and STOMP, though STOMP's semantics are pretty
>> loose) are
>> not quite what you'd expect given what they mean in the DB world. They are
>> used
>> to *group* sets of messages ("SEND"s) together (atomically, more or less)
>> so
>> that either all or none are published. An additional wrinkle is the
>> treatment
>> of acknowledgements ("ACK"s) of messages delivered to the transacting
>> client
>> from the server: acknowledgements can be included in a transaction along
>> with
>> new publications.
>>
>> This lets e.g. an RPC server receive a request, process it, and then
>> transactionally both acknowledge the request and send the reply message.
>> If the
>> transaction commits, the request is deleted from the server's queue, and
>> the
>> reply is enqueued for the RPC client; if the transaction aborts, the
>> request
>> remains enqueued waiting for another (or perhaps the same) RPC server
>> instance
>> to pick it up and work on it, and the reply message is not sent.
>
> Right, this was my guess. But then I tried making a sunit test and... well,
> I start two sessions, let the first set up a subscription to 'wonderland',
> then let the second session do BEGIN and send two messages to 'wonderland',
> now, my naive understanding was that session one should not receive any
> message until session2 does COMMIT.
>
> But perhaps what is happening is that the messages are not *removed* from
> the queue until COMMIT? Hmmm. Ok. <scratching head> wonder how to rig a unit
> test for that.
>
>> With regard to hitting disk: persistence of messages is orthogonal to
>> their
>> transactionality in messaging systems like AMQP and STOMP.
>
> Right, kinda guessed.
>
>> I hope this helps. I read squeak-dev, too, so feel free to get in touch in
>> either place if you have further questions.
>
> Sure!
>
>> Regards,
>>   Tony
>
> regards, Göran
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>