The AMQP transport implementation for Apache Synapse and it's now ready for production use. This is an overview of the new transport here. This transport is now part of Apache Synapse and will be available with the next release.
The transport has an interesting list of features. It has a rich set of configuration options which can be used to configure the various bits and pieces of the transport. The feature list includes;
- Publish/Subscribe(fanout exchange).
- Worker queue(fair dispatching of worker task in a round robin manner).
- Routing(direct exchange).
- Publish/Subscribe to a topic(topic exchange).
- Transactions support and message acknowledgement
- Two way messaging support.
In order to achieve better performance the transport caches AMQP objects(connections and channels). The connections and channels are cached at the producer and consumer side. The polling task has an asynchronous architecture where I/O task actually poll the message from AMQP broker and place into an instance of BlockingQueue(in the implementation an instance of LinkedBlockingQueue was used). Once the message is placed into this buffer a separate worker task will actually process the message. All these worker pools can be configured for the requirements. At the sender side it's recommended to remove the parameter 'ClientApiNonBlocking' for high load deployments in order to avoid creating a new thread for each message that send out.
The polling tasks are based on ScheduledExecutorService. Configuration parameters are defined to configure the scheduled executor service. The transport is also equipped with an high availability implementation. If the broker goes offline this task will schedule a heart beat task which will tries to connect to broker in an exponential back-off fashion. This high availability task will suspend the current polling tasks until a successful reconnect attempt is made. This make sure that the Apache Synapse doesn't run out of disk space because of continuous logging of failing polling tasks.
The transport was profiled and exposed to heavy load to test the stability. I just pumped 10,000,000 messages and the system was able to process all of them smoothly. Below is the screen shots for memory and threads usages of the system under heavy load. It can be seen that the periodic GC cycles with a stable memory(after couple of repeating patterns the memory usage tend to become stable) and thread usage.