Compression inconsistenty

In the latest release of MailerQ, we've introduced a feature to compress the data that is sent through RabbitMQ. We sadly made a mistake with the implementation. We therefore advise you not to use compression yet, and wait for the upcoming bugfix release.

What went wrong?

In the documentation you can read that MailerQ inspects the "content-encoding" property of the AMQP envelope that is wrapped around message consumed from RabbitMQ. If this property is set to "gzip", MailerQ treats the message as a compressed message and will decompress it before it processes it further.

This documentation is correct. However, in our implementation we made a slight mistake. Instead of inspecting the "content-encoding" property of the envelope, we inspect the "headers" property. This "headers" property can hold a table of user-supplied key/value pairs. Inside this "headers" table we then check whether a "content-type" key is set, and if this is the case and the associated value inside this table is set to "gzip", we consider the message to be compressed.

The implemented algorithm is different than the algorithm described in the documentation, which ignores the "headers" property, and only checks the "content-encoding" property of the envelope.

We've decided that the documented algorithm is more logical than the implemented one. We will therefore change the algorithm. In the next version we will no longer check the "headers" property, and use the "content-encoding" property instead. To prevent that this breaks compatibility with existing setups, we therefore recommend to wait with using compression until the next version of MailerQ.