The deprecated feature flag `amqp_filter_set_bug` was introduced in
RabbitMQ 4.1 with phase `permitted_by_default`.
See https://github.com/rabbitmq/rabbitmq-server/pull/12415
This commit which will land in RabbitMQ 4.2 changes the phase to `denied_by_default`.
JMS:
> A string literal is enclosed in single quotes, with an included single quote represented
> by doubled single quote; for example, 'literal' and 'literal''s'.
AMQP SQL
https://docs.oasis-open.org/amqp/filtex/v1.0/csd01/filtex-v1.0-csd01.html#_Toc67929302
> A string constant is a string of arbitrary text consisting of any valid printable Unicode
> characters surrounded by single or double quotation marks. A quotation mark inside the
> string is represented by two consecutive quotation marks.
> string_constant ::= { ‘ | “ } <any> [<any>] { ‘ | “ }
Allow only upper case predefined selector literals and operator names.
The JMS spec states:
> Predefined selector literals and operator names are written here in upper case; however, they are case insensitive.
However, the AMQP SQL spec does not include such a statement.
The EBNF notation with single quotes ('AND') typically implies exact literal matching.
This commit follows the AMQP SQL's EBNF notation and therefore disallows
lower case predefined selector literals or operator names.
AMQP SQL spec:
"The left operand is of greater value than the right operand if:
... both operands are of type string or of type symbol (any combination is permitted) and the
lexicographical rank of the left operand is greater than the lexicographical rank of the right operand."
In contrast, in JMS:
"String [...] comparison is restricted to = and <>."
The spec is underspecified in what should happen if the left hand side
is a float. This commit decides that the result is undefined (unknown).
The spec is also underspecified in what should happen if either the left
hand side or the right hand side is negative. This commit decides to use
the behaviour of Erlang `rem`.
This commit fixes the following test case:
```
make -C deps/rabbit ct-amqp_dotnet t=cluster_size_1:fragmentation
```
Previously, the server sent a frame that was 1 byte too large.
This commit fixes the failing test cases
```
make -C deps/rabbit ct-msg_size_metrics t=tests:message_size
make -C deps/amqp10_client ct-system t=rabbitmq:roundtrip_large_messages
```
The second test case failed with:
```
flush {amqp10_event,
{connection,<0.193.0>,
{closed,
{framing_error,
<<"frame size (131073 bytes) > maximum frame size (131072 bytes)">>}}}}
```
This commit results in great performance improvements for AMQP 1.0.
Stream filtering via AMQP SQL Filters or AMQP Property Filters where the
broker reads messages from the stream into memory and the filter returns
false, i.e. messages are not sent to the client:
Before this commit: ~400,000 msgs/s
After this commit: ~500,000 msgs/s
There is also a ~10% increase in end-to-end throughput for normal
AMQP workloads, e.g. when sending to and receiving from a classic queue.
Prior to this commit, a lot of garbage was created leading to many minor
garbage collections.
This commit reduces the garbage being generated.
The new module amqp10_composite performs very well:
* Single tuple update setting multiple fields at once, sometimes done even in-place
without copying the tuple.
* The list of fields is passed into X registers, no need for any new
allocations.
On the serialisation side, this commit also generates less garbage by:
1. Avoiding tuple_to_list/1
2. Omitting trailing elements of the list that are null
This will also lead to fewer bytes per message sent on the wire and less
resource usage for the clients as they need to parse fewer fields.
The closing sequence must account for consumer update and metadata
update frames the broker sends when a consumer group changes and when a
stream is deleted.
Michal Kuratczyk
David Ansari
Arnaud Cogoluègnes
Michael Klishin