[rabbitmq-discuss] Claim on new ocamlmq broker...

[Tony Garnock-Jones]

Matthew Sackman wrote:
> - our STOMP adapter was written by TonyG and is largely unloved.

I dunno, I love it a little :-)

Questions and bug reports are welcome, in particular, and we have had an OK
track record on responding to them in the past, even though the STOMP adapter
isn't "officially supported".

> If STOMP does give publisher acks, then it's possible that the adapter is 
> not using AMQP transactions, and thus the publisher ack does not indicate
> any sort of reliability concerns.

It gives optional "receipts" for messages. You're right, the STOMP adapter is
not using the underlying AMQP transaction mechanism, and therefore STOMP's
transactions don't force an fsync. This is arguably a bug, but the difference
between STOMP's transaction semantics and AMQP's transaction semantics is
difficult to bridge in the adapter without support from the core code. STOMP
supports multiple outstanding transactions on a single channel-like object,
unlike AMQP.

> That said, I was also under the impression that STOMP quite deliberately has
> no semantics whatsoever - if this is the case then it would seem to be
> completely legitimate to issue the publisher ACK without using a
> transaction.

Exactly right :-)

To sum up: the STOMP adapter covers a broad range of messaging, but by no means
as broad a range as the core AMQP adapter can cover. It's good for using to
bridge to systems that don't have an AMQP client library yet, and for
connecting to certain legacy applications, but where you have the choice, the
built-in AMQP adapter is far better because it is

 - officially supported,
 - well-defined in its behaviour (by the AMQP spec), and
 - actively developed and tuned,

none of which can be said about the STOMP adapter.

Tony