AMQP revamp in Zato 3.0
Zato 3.0 will sport a completely rewritten AMQP subsystem and the changes are nothing short of exciting. Put simply, everything is faster, leaner and even more robust.
AMQP channels are now synchronous which means that an AMQP broker will wait for a Zato service to confirm that the message was received or it was not. In earlier Zato versions, AMQP channels worked in an implicit always-acknowledge mode. Now each message taken off an AMQP queue can be explicitly acknowledged or rejected, as below:
from zato.server.service import Service class MyService(Service): def handle(self): if 'foo' in self.request.payload: self.request.amqp.ack() else: self.request.amqp.reject()
Channels have access to all metadata regarding an incoming message, for instance:
from zato.server.service import Service class MyService(Service): def handle(self): self.logger.info(self.request.amqp.msg)
Previously, a single connection pool was shared by all channels and outgoing connections to a single AMQP broker.
Now each channel or outgoing connection may have its own pool, managed independently, which lets Zato servers use multiple CPUs in AMQP connections to improve performance - the underlying framework for connection pools was redesigned to achieve drastically reduced RAM usage - from megabytes down to kilobytes for each pool.
Correlating connections and consumers
When using AMQP GUIs, it was already possible to easily find Zato connections but the idea has been extended and now each connection, channel and consumer carry accounting information on which Zato component is the source or consumer of a message, including remote hostname, process ID, thread/greenlet ID and consumer tag prefix:
Get it from GitHub
A preview version of Zato 3.0 can be already installed from source code