On 06/04/2018 06:59 PM, Ken Dreyer wrote: > On Mon, Jun 4, 2018 at 8:30 AM, Jeremy Cline <jeremy@xxxxxxxxxx> wrote: >> 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 >> example). > > 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 anyway. 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 > problem :) 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 helpful! -- Jeremy Cline XMPP: jeremy@xxxxxxxxxx IRC: jcline _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx/message/3TANO67CR6YLNIRT6WUZDG63VLPHPU3Q/
