RabbitMQ¶
The official "hello-world" example for python on RabbitMQ's homepage describes a message broker in the following way:
RabbitMQ is a message broker: it accepts and forwards messages. You can think about it as a post office: when you put the mail that you want posting in a post box, you can be sure that Mr. or Ms. Mailperson will eventually deliver the mail to your recipient. In this analogy, RabbitMQ is a post box, a post office and a postman.
The major difference between RabbitMQ and the post office is that it doesn't deal with paper, instead it accepts, stores and forwards binary blobs of data ‒ messages.
For every registered application in Lime CRM, there is an exchange (or a post box) in RabbitMQ.
Every time an object is created, updated or deleted in the platform, a message is published to that application's exchange.
The object event can then be subscribed to using an Event handler. A subscription is called a binding in RabbitMQ and that includes the specification (the routing key) of what events to subscribe to, and the queue to use. So an event handler subscribing to all "Person" events, would have a queue with messages for all created, updated and deleted person objects. These messages are copies of the events published from any of the application services.
Configuration¶
Communication to RabbitMQ goes through the AMQP protocol over port 5672.
Any service (e.g. Event Handler, Task Handler, Web Server) publishing to RabbitMQ can be configured as:
Services (Event Handler) consuming events from RabbitMQ can be configured as:
events:
connection_string: amqp://guest@localhost//
consumer_heartbeat: 15
tcp_keepalive_timeout: 120
connection_string¶
The connection string to the RabbitMQ installation.
consumer_heartbeat¶
This option is used to define the interval, in seconds, of AMQP level heartbeats, of consumer connections.
Heartbeats can be used to ensure the connection between RabbitMQ and event consumers are alive and well.
If RabbitMQ doesn't receive a heartbeat over AMQP within a specified period of time it will assume the consumer is offline or has encountered and error.
Use this setting when encountering unexpected connection losses in the event handler and TCP keepalives doesn't work.
Read more about sane values for AMQP heartbeats in the RabbitMQ documentation
tcp_keepalive_timeout¶
This option defines the duration of time, in seconds, for which TCP keepalive packets are sent to client machines in order to keep a connection alive. It means that the server basically asks the client to send a sign of life in order for the server to know whether this connection is healthy (alive) or not.
This value should be assigned a value that is less than the connection timeout value of firewalls or proxies that might terminate a connection.
Similar to consumer_heartbeat this option can be used to adjust the period used to make sure connections are kept alive between RabbitMQ and services publishing events or celery tasks.
In situations where the broker is behind a load balancer or similar, it may be required to use AMQP heartbeats instead.
tcp_keepalive_interval¶
This option specifies the time, in seconds, between individual keepalive probes once the keepalive mechanism has been triggered. If no acknowledgment is received for a probe, the server waits for this interval before sending the next one.
A shorter interval makes failures detected more quickly but increases network traffic. A longer interval reduces network chatter but delays detection of broken connections.
tcp_keepalive_count¶
Note: On macOS and Windows operating systems this can't be changed.
This option defines the maximum number of keepalive probes that will be sent before the connection is considered dead. If the server sends this many probes without receiving any response from the client, the TCP connection is dropped.
Together with tcp_keepalive_timeout and tcp_keepalive_interval, this value determines how long it takes to detect a dead peer and close the connection.