On 06/04/2018 06:59 PM, Ken Dreyer wrote:
On Mon, Jun 4, 2018 at 8:30 AM, Jeremy Cline
> I had a hard time justifying choosing STOMP over AMQP because most
> brokers just map the other protocol they focus on onto STOMP. It's true
> the the spec is short, but it leaves a lot up to individual
> implementations as far as I can tell (like how topic matching works, for
It's nice to give the flexibility to clients by exposing both. I
haven't seen a problem with topic matching in my experience so far.
I read up a bit on the RabbitMQ plugin for STOMP, it sounds like it uses
the same routing key rules (e.g. '*' and '#' work) as the AMQP queue
bindings in Rabbit. I don't have a problem with them both being exposed
in the Fedora deployment.
I don't mind the fedora-messaging library using STOMP either, but people
will still need to understand the AMQP semantics because we're relying
on using two different exchanges to track what messages came from ZeroMQ
vs AMQP, and Rabbit maps all the STOMP interaction onto AMQP concepts
I would like to make our work easily usable by Red Hat internal
infrastructure since that can only be a beneficial relationship for both
Fedora and Red Hat, but I don't have a good sense of what they're doing.
Mike, if your suggestion is driven by a desire to make this a useful
tool internally, please let me know. My current impression is that
the client and protocol it uses is of minimal interest. I imagine the
schema would be of interest, though. Am I wrong here?
One thing I found with AMQP vs STOMP is that it's possible for AMQP
clients to (accidentally) emit "binary" message bodies, and then
ActiveMQ does not translate or expose these as plaintext JSON for
STOMP clients. It just looks like an empty message body to STOMP
clients, or possibly garbage. The solution was for clients to
translate the messages to text/json prior to sending. (Of course if
you never enable STOMP on your broker at all, maybe this won't be a
The fedora-messaging publish/subscribe API (that's just wrapping an AMQP
client) requires the message to match a jsonschema, that it is UTF-8
encoded, and that the content type and encoding is properly set so if
some publisher is misbehaving in this way the clients using
fedora-messaging will reject this sort of message.
Thanks for sharing your experience with AMQP and STOMP, it's very