#13873 by @Ayanda-D, polished and rebased #15166
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…it_quorum_queue api
check existing cluster membership when growing to a node.
… in QQ grow-to-N command and update banner
This reverts commit 15ce0b51af294b15f183da57ea2e040362bccbe7.
… and continue waiting
…etries/2 to continue waiting"
## What? If a receiver performs stream filtering with AMQP property filters or AMQP SQL filter expressions, the following downsides can occur: 1. While the stream is being filtered, other links on the same session are blocked 2. RabbitMQ sends messages late to the receiver As an example, let's assume a receiver attaches to the start of a multi GB stream providing a link credit of 2. Let's assume only the very first message matches the filter. In this case, RabbitMQ scans the entire stream without processing other links on the same session, and sends the matched message only once the scan completed (after many seconds or even minutes). Instead, we want other links to be processed concurrently and the receiver might want to start processing the first matched message while RabbitMQ continues filtering the stream. This commit fixes these two downsides. ## How? After a threshold of consecutively unmatched messages, the session "pauses" filtering on that link temporarily by: 1. sending an Erlang message `resume_filtering` to itself, and 2. sending any matched messages to the receiver Any other Erlang messages then have a chance to be processed by the session before the filtering on that link is resumed by the `resume_filtering` Erlang message. Once the end of the stream is reached or link credit is exhausted, the `credit_reply` will be returned from `rabbit_stream_queue` to `rabbit_amqp_session`. An alternative solution would be to use separate Erlang processes for filtering links as they can be CPU bound and also block for disk I/O.
Switch from ra_metrics to ra_counters * Expose many more metrics (they are also up to date) * Bump Seshat, Ra, Osiris, Prometheus.erl * switch from proplists to maps
... when testing vhost limits [Why] The tracking is aynchronous, thus the third MQTT connection might be opened before the tracking is up-to-date, which the testcase doesn't expect.
Sometimes a plugin needs to list online peers that are running, reachable, not under maintenance and have a specific plugin enabled. This commit introduces a few helper functions to make such cluster member queries trivial.
with Selenium. And ci job to build the docker image
This partially reverts #14245. This makes 4.2 <-> 3.13 mixed version tests succeed. We can set this flag to `denied_by_default` in 4.3.
Prior to this commit, quorum queue at-most-once dead lettering for the overflow behaviour `drop-head` was dead lettering in the wrong order.
PR #14926 added a test case that checks that quorum queues at most once dead letter in the correct order for reason `maxlen`. This commit adds tests for dead letter reasons `rejected`, `delivery_limit`, and `expired`.
Set charset=utf-8 in Content-Type header to ensure proper display of Cyrillic and other Unicode characters in browsers. Fixes #13952
Replace manual header setting with charsets_provided/2 callback to let Cowboy handle charset negotiation automatically.
## What? 1. This commit adds the name of the queue that rejected a message as well as the reason why the message was rejected in the Rejected outcome for AMQP 1.0. 2. For MQTT 5.0 publishers, the reason is provided in the PUBACK packet. ## Why? It may be helpful for publishers to know which queue out of multilple target queues rejected the message. One such use case is described in #1443 It may also be helpful to know for publishers whether the given target queue rejected the message because its maximum queue length was reached or because the target queue happens to be unavailable. ## How? RabbitMQ will include the UTF-8 encoded queue name (rather than an AMQP address) as well as the reason in the `info` field of the Rejected outcome's `error` field: * `queue: <queue name>` * `reason: maxlen | unavailable` For MQTT 5.0, if the queue length limit is exceeded, RabbitMQ will return the reason code for `Quota exceeded` to the publisher.
When a client attaches an AMQP 1.0 receiver link without specifying a
source address, RabbitMQ crashes with a `function_clause` error and
returns an Erlang stack trace to the client. This makes it difficult for
developers to understand what went wrong.
Previously, the client received:
```
SessionError: function_clause
[{rabbit_amqp_session,ensure_source,
[undefined,false,<<...>>,<<...>>,
{user,<<...>>,[administrator],[...]},
<<...>>,<0.585.0>,[],[]],
[{file,"rabbit_amqp_session.erl"},{line,2665}]},
{rabbit_amqp_session,handle_attach,2,...},
...]
```
This change adds a new clause to `ensure_source/9` that catches the case
where the source is `undefined`. Instead of crashing, the function now
returns `{error, source_address_required}`, which `handle_attach/2` maps
to an `amqp:invalid-field` error with a clear message.
Now, the client receives:
```
LinkError: Attach refused: source_address_required
condition: 'amqp:invalid-field',
description: 'Attach refused: source_address_required'
```
The error condition `amqp:invalid-field` is appropriate here because the
client failed to provide a required field in the attach frame, not
because a resource was not found.
Also added a test for an `undefined` receiver address.
Fixes #14300
michaelklishin
changed the title
Collaborator
Author
|
I would not even try to backport this via Mergify => removed the tag. |
12 tasks
Merged
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is #13873 by @Ayanda-D with clarifying comments and one CLI command fix from me.
Due to over 600 commits rebased, this branch has accumulated dozens of commits that are only recorded due to conflict resolution. The actually meaningful part of the diff should be very comparable to #13873.