This is more straightforward than configuring Osiris in the advanced
configuration file.
(cherry picked from commit eeb35d2688)
(cherry picked from commit f7d6424d42)
# Conflicts:
# deps/rabbit/priv/schema/rabbit.schema
This contains a fix in the ra_directory module to ensure
names can be deleted even when a Ra server has never been started
during the current node lifetime.
Also contains a small tweak to ensure the ra_directory:unregister_name
is called before deleting a Ra data directory which is less likely
to cause a corrupt state that will stop a Ra system from starting.
(cherry picked from commit 42991f7838)
(cherry picked from commit a6a2f645e0)
# Conflicts:
# MODULE.bazel
# rabbitmq-components.mk
The AMQP 0.9.1 longstr type is problematic as it can contain arbitrary
binary data but is typically used for utf8 by users.
The current conversion into AMQP avoids scanning arbitrarily large
longstr to see if they only contain valid utf8 by treating all
longstr data longer than 255 bytes as binary. This is in hindsight
too strict and thus this commit increases the scanning limit to
4096 bytes - enough to cover the vast majority of AMQP 0.9.1 header
values.
This change also conversts the AMQP binary types into longstr to
ensure that existing data (held in streams for example) is converted
to an AMQP 0.9.1 type most likely what the user intended.
(cherry picked from commit 131379a483)
- Timestamps are milliseconds in AMQP 1.0, but in AMQP 0.9.1 it is seconds.
Fixed by multiplying the timestamp by 1 000.
- Shovel crashed if user_id was set in the message because the encoding
was as utf8 while it should be a byte array.
- Negative integers were encoded as integers - therefore leading to
incorrect positive values.
- Float values were not supported by the client.
- Fixed priority header encoding in AMQP 1.0. It was set as uint but it
should be ubyte.
- Priority of the message is now in the Headers instead of Application
Properties. This is potentially a breaking change.
Fixes: #7508
(cherry picked from commit 8e954ff366)
`ets:whereis/1` adds some overhead - it's two ETS calls rather than one
when `ets:whereis/1` returns a table identifier. It's also not atomic:
the table could disappear between `ets:whereis/1` calls and the call to
read data from a projection. We replace all `ets:whereis/1` calls on
projection tables with `try`/`catch` and return default values when we
catch the `badarg` `error` which ETS emits when passed a non-existing
table name.
One special case though is `ets:info/2` which returns `undefined` when
passed a non-existing table names. That block is refactored to use a
`case` instead.
(cherry picked from commit 9f255db90f)
(cherry picked from commit 787897dc23)
Projections might not be available in a mixed-version scenario where a
cluster has nodes which are all blank/uninitialized and the majority
of nodes run a version of Khepri with a new machine version while the
minority does not have the new machine version's code.
In this case, the cluster's effective machine version will be set to
the newer version as the majority of members have access to the new
code. The older version members will be unable to apply commands
including the `register_projection` commands that set up these ETS
tables. When these ETS tables don't exist, calls like `ets:tab2list/1`
or `ets:lookup/2` cause `badarg` errors.
We use default empty values when `ets:whereis/1` returns `undefined` for
a projection table name. Instead we could use local queries or leader
queries. Writing equivalent queries is a fair amount more work and the
code would be hard to test. `ets:whereis/1` should only return
`undefined` in the above scenario which should only be a problem in
our mixed-version testing - not in practice.
(cherry picked from commit c490043484)
(cherry picked from commit 7c1efbbde4)
Without buildbuddy for parallelization and with the change in the parent
commit to reduce the number of cases, the suite now runs fast enough
that sharding is counterproductive.
(cherry picked from commit 95279a31ec)
# Conflicts:
# deps/rabbitmq_consistent_hash_exchange/BUILD.bazel