Highlights MailerQ 0.6
MailerQ version 0.6 brings a number of new features. It has been six weeks since version 0.5 and the development team has managed to use this time to fix some bugs and add new features.
Retry queue
An extra optional queue can be assigned to use for retry attempts. Previously, MailerQ published messages to one or more of the result queues only when the delivery was fully completed (succesfully or with an error). Interim failures that triggered a retry were not published to a result queue, but to the outbox where they were later picked up again. Because of this, it could take up to days before a message would finally appear in one of the result queues.
With the optional retry queue you can however now specify a queue that will be filled with all retry attempts. When such a queue is set, MailerQ will not only publish the retries back to the outbox queue, but also to this retry queue.
The retry queue is set in the same was as the other result queues are set: either in the JSON encoded message, in the config file or as a command line option.
Support for other database engines
MailerQ is no longer limited to MySQL, but now also supports PostgreSQL and Sqlite. You can use the database of your choice. The default setup has been changed to use Sqlite because of the enormous simplicity to set it up, although MySQL and PostgreSQL do have better performance. Because MailerQ only uses the database for simple tasks (configuration and statistics), Sqlite is however powerful enough in normal operations.
The message store that was previously limited to Couchbase, can now also be configured to use Mysql, PostgreSQL or Sqlite. However, although we do offer support for these SQL database as message stores, we advise strongly against it. Couchbase is much more suitable. In fact, if you do not currenly have a Couchbase server, it is better to set up MailerQ without a message store (MailerQ will work just as well), than it is to use SQL for this.
More fine grained delivery limits
The delivery capacities (max number of messages per minute, max number of open connections, et cetera) that were configurable on a per-domain basis, can now be different for each outgoing IP address.
Thus, where it used to be only possible to install a limit as "do not send more than 1000 messages per minute to example.org" for all from IPs at the same time, you can now also set limits for individual IP addresses. "Do not send more than 1000 messages per minute to example.org from IP address 1.2.3.4, and do not send more than 30 messages per minute to example.org from IP address 1.2.3.5".
Changes to the management console
Many changes and improvements to the management console were added. The log page has been completely redesigned, and the charts can now also show the number of deliveries per second. These are two of the most notable changes, but many other changes and improvements were added too.
Important bug fixes
MailerQ uses an external AMQP library to communicate with RabbitMQ. However, it turned out there is a memory leak in this library that causes MailerQ to consume more and more RAM the longer it runs. We have altered MailerQ to work around this bug.
