BlazingMQ: High-performance open source message queuing system
I&#x27;m the developer of the Message-Oriented Async RPC library Mats3: <a href="https:&#x2F;&#x2F;mats3.io&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;mats3.io&#x2F;</a><p>Its current sole implementation is based on Java Messaging Service JMS API, and it is used in production for a rather large UCITS unit holder registry on Apace ActiveMQ, and all tests runs fine on Apache Artemis MQ.<p>Every time a new message broker comes along, I sit up in the chair and wonder a) about their performance (!), and b) whether they have a JMS client implementation, and c) whether Mats3 works with that! When I tested RabbitMQ&#x27;s JMS client library, I sadly found that there was rather many differences - things I thought was screamingly obvious, was not available. E.g. as basic function as redelivery: &quot;Normal&quot; MQs try to redeliver N times, typically with a backoff between each attempt, and then, when all N attempts fail, it puts the message on the DLQ. Rabbit instead tight-loops the delivery attempts until either the message goes through, or the sun burns out. To be able to use Rabbit, I would have to use the native API, and implement redelivery and DLQing myself, client side. Also, transactions.<p>I now wonder whether I should make a lower-level abstraction, so that the JMS implementation is converted to a &quot;base&quot; impl, and then the JMS, Rabbit, Bloomberg, NATS, ZeroMQ, Aeron, etc implementations was extensions, or &quot;plugins&quot;, or &quot;drivers&quot;, to that.