The new client library version returns reason
`{shutdown, connack_timeout}` in the monitor message.
Delete the monitor since the test case already asserts on the
`{error, connack_timeout}` return value from emqtt:connect/1.
Namely, 'starting'.
Previously, a Prometheus scraping endpoint hit
just at the right moment (when a shovel was
in the 'starting' state) would produce
a function_clause exception.
Bumps the dev-deps group with 1 update in the /deps/rabbit/test/amqp_jms_SUITE_data directory: org.apache.qpid:qpid-jms-client.
Updates `org.apache.qpid:qpid-jms-client` from 2.7.0 to 2.8.0
---
updated-dependencies:
- dependency-name: org.apache.qpid:qpid-jms-client
dependency-version: 2.8.0
dependency-type: direct:development
update-type: version-update:semver-minor
dependency-group: dev-deps
...
Signed-off-by: dependabot[bot] <support@github.com>
These lines can be very useful for determining why a subset of feature
flags is/isn't being enabled on boot. They're currently at debug level.
However a first-time boot of an unclustered node is a rare event, so
these lines shouldn't be noisy.
Commit e435bc6886 introduced behavior in
creating the source-dist archive that sets the file modification time to
the same time as the most recent `git` commit. This facilitates
reproducible builds, but it also has an issue. The code sets `TZ=`,
which means that on systems running in time zones which aren't UTC, the
modification time may be in the future (or past). It depends on the
system's behavior.
Up until recently, this only resulted in GNU make printing warnings
about modification times being in the future. However, with recent
changes in how escripts are built, this results in an "infinite make
loop" that is described in https://github.com/rabbitmq/rabbitmq-server/discussions/14440
and https://github.com/rabbitmq/rabbitmq-server/discussions/14443
This solution is to set the `TZ=UTC` when calculating the time of the
most recent `git` commit, as well as when using `touch -t` to set the
file modification times.
Fixes#14440, #14443
## What?
Refuse or detach the link instead of ending the session for many
link-level errors, including the following:
* Source queue or target exchange doesn't exist during attach
* Trying to consume from an exclusive queue on a different connection
* Delivery of message to a target queue fails
* Wrong delivery-id
* Wrong settled flag
* Queue declaration fails for dynamic queues
* Publishing to internal exchange
## Why?
Because many errors are scoped to a single terminus, detaching just that link
preserves the rest of the session’s links - avoiding needless disruption of
other traffic. AMQP 1.0’s error model is hierarchical; RabbitMQ should escalate to
ending the session only for session-level faults or if the client keeps
using a destroyed link.
## How?
Refuse link as per figure 2.33
Michael Klishin
David Ansari
Michal Kuratczyk
D Corbacho
dependabot[bot]
Karl Nilsson
Michael Davis
Luke Bakken
Péter Gömöri
Aitor Perez
Marcial Rosales
Diana Parra Corbacho