The RabbitMQ community has created a large number of clients and developer tools covering a variety of platforms and languages. Community Plugins For your convenience, we offer binary downloads of various plugins developed by the community. RabbitMQ offers a variety of features to let you trade off the performance with reliability including persistence, delivery acknowledgments, publisher confirms, and high availability.

AMQP-CPP-xcode-example A RabbitMQ message broker C11/C++ client Mac Xcode example project built on Copernica's AMQP-CPP library. Sample work created to show my command of the C11/C++ language, demonstrate some good design practises and real-time development patterns/techniques. This repo shows how to use Copernica’s AMQP-CPP C++ library to create a RabbitMQ client. The Xcode project contains 2 sample command line apps for message 'Sender' and 'Consumer' clients. Everything which begins with “My” is my code.

Most of my interesting stuff described below is in the MyAMQP directory. Everything in the AMQPSTL directory is code from Copernica packaged into a dynamic library for ease of Xcode on OS X development. How to run On mac I chose this installation I moved it into /opt/local because I know that OS X does not use this directory (it is the directory used by macports). • Start the rabbitMQ server in a shell window. Sudo./rabbitmq-server • Start the consumer from the build location in another shell window.

For a quick test of the non packaged debug build: cd ~/Library/Developer/Xcode/DerivedData/AMQP./Build/Products/Debug export DYLD_LIBRARY_PATH=./Consumer • Start the sender from the build location in another shell window: export DYLD_LIBRARY_PATH=./Sender You should see 100 messages transmitted and received. To show some of the reliability features offered by a message broker try the following: • Kill the Consumer. • Run the Sender again. NB Consumer is not running. • Start up the Consumer and note how it receives the messages buffered in the rabbitMQ broker. To Load test, run the sender with a large message count:./Sender --count 1000000 Software design techniques demonstrated are: Threading/performance considerations. I can see from the debugger that the user message receive callback from the Copernica library is being invoked in the context of the network read thread.

So to avoid message processing in the client holding up network writing in the RabbbitMQ server due to TCP flow control, messages are queued in the context of the network read rather than processed. The MyTaskProcessor class takes a modern approach to queueing and processing in its own thread. See below for details on how I did this using std::packaged_task and std::async. Similarly the debugger tells me that the Copernica API to send the message Ack involves a network write in the same thread context as the API call. So instead of potentially holding up the message processing by blocking on a network write, the sending of acks are also handled by another thread (via the MyAckProcessor class). See below for details on how std::future is waited on for sending the acks. The Consumer app has command line options to either perform the above threading or process all messages and acks in the context of the user handler for benchmark comparison reasons.

Benchmarking on the loopback does not show a performance improvement with the threaded option, however the loopback does not behave the same as the LAN/WAN. In the situation where a bursts of messages are arriving and being allowed to pile up on the task and ack queues and message processing is blocking e.g. Playing avi files on mac. Remote database operations, I would expect this state of affairs to outperform the simple model which holds up network operations from the server and holds up message processing on the network writes. If I simulate a network delay in sending acks with a small sleep on each ack write, then running the app in threaded mode processes the messages considerably faster.

This is due to the concurrent processing of messages and ack sending. Using a benchmark of 1000 messages and a delay of 1 millisecond per ack the threaded model runs 10 times faster!

The impl or hidden implementation. Implementation include files are confined to the impl and hidden from the wrapper class by use of a forward declaration for the impl. This reduces application dependencies, speeds application compilation and it is easy to make the wrapper object movable. See MyAMQPClientImpl in the MyAMQP directory and note that all the non 'impl' classes and include files are hidden from the application in this impl. Also see MySignalHandler in the MyUtilities directory for how an impl can be used to make platform specific variants. Another style of impl I have used is the POD (plain old data) which is just a hidden struct and all control flow logic is held in the owning class.