Now that all the fancy Federation/HA knobs and whistles are implemented in RabbitMQ as policies in the broker, using STOMP via the plugin shouldn't omit any functionality. This code has a number of advantages:
Is written around libevent so it's non-blocking, while librabbitmq is written as a blocking client, this means in the dequeue daemon we sit in the libevent dispatch loop and can do things like periodically fire off statistics about the dequeue daemon rather than sit waiting on receiving AMQP frames, see #15.
Pertains to support SSL, see #9.
Heartbeat support.
Would allow use of other STOMP brokers such as ActiveMQ as well as RabbitMQ.
Might be quicker?
Obviously another thing would be to either make librabbitmq work as non-blocking, or even consider writing a non-blocking libevent-based AMQP client, (this has been considered on more than one occasion!), however the STOMP protocol is very straightforward.
Consider supporting STOMP via https://github.com/bodgit/libevent-stomp
Now that all the fancy Federation/HA knobs and whistles are implemented in RabbitMQ as policies in the broker, using STOMP via the plugin shouldn't omit any functionality. This code has a number of advantages:
Obviously another thing would be to either make librabbitmq work as non-blocking, or even consider writing a non-blocking libevent-based AMQP client, (this has been considered on more than one occasion!), however the STOMP protocol is very straightforward.