Put configuration credit_flow_default_credit into persistent term such
that the tuple doesn't have to be copied on the hot path.
Also, change persistent term keys from `{rabbit, AtomKey}` to `AtomKey`
so that hashing becomes cheaper.
1. Link to up-to-date version of code describing Osiris chunk.
2. Update `Deliver` command description with Bloom filter entries.
3. Add information about use of `Publish` command with filter value. The
hint about use of version 1 or 2 is based on the Java client
implementation.
Dynamic Shovels keep track of their status in
a node-local ETS table which is updated as
Shovels go through the lifecycle: start,
init (connect, declare the topology), stop.
This makes failing Shovels a bit special:
their status records will not be long lived,
which means it will be considered not to exist
by certain code paths.
In addition, for such Shovels we do not know what
node they are hosted on. But that's fine:
we just need to clear their runtime parameter
and a periodic Shovel cleanup will remove all
children for which no schema database entry
(a runtime parameter one) does not exist.
rabbitmq_shovel_management's key integration
suite has been reworked and expanded to include
a case where the Shovel has no chance of
successfully connecting.
This also deletes a mock-based test suite
which does not serve much of a purpose.
[Why]
Depending on the exit status of the writer process when a testcase calls
it, the exception reason might differ. From the actual error if the
writer was called before it handled the error, to `noproc` if it already
exited.
[How]
We match against several probable exception reasons that would signify a
success for the testcase.
[Why]
The writer process could still be exiting at the time flush is called.
For instance, the reason could be `{shutdown, _}`.
Also, with the conversion of the `rabbit_writer` to a gen_server, the
noproc reason would be `{noproc, _}`.
[How]
`flush_writer/1` is called in the channel `terminate/2` function, so we
don't really care about any writer errors at this point. Let's ignore
any exceptions.
... after `rabbit_writer` conversion to gen_server.
[Why]
The `rabbit_writer` being a regular gen_server now, it will stop with
the reason `{shutdown, Reason}`. Otherwise this would be considered a
crash by the supervision tree and it would log even more scary errors
and stacktraces.
[How]
If the reason is `{shutdown, _}`, we just unpack the embedded reason and
use it for the channel stop reason. This ensures the behavior of the
channel process doesn't change.
[Why]
This process failed to implement properly the OTP principles. For
instance, the mainloop always kept a reference on the module because it
was not tail-recursive.
This prevents the module from being reloaded at runtime: because the
process always keep that reference on the module, it is killed by the
Code server as part of the code reloading.
The issue comes from a mechanic that allows us to avoid writing
to disk when a message has already been consumed. It works fine
in normal circumstances, but fan-out makes things trickier.
When multiple queues write and read the same message, we could
get a crash. Let's say queues A and B both handle message Msg.
* Queue A asks store to write Msg
* Queue B asks store to write Msg
* Queue B asks store to delete Msg (message was immediately consumed)
* Store processes Msg write from queue A
* Store writes Msg to current file
* Store processes Msg write from queue B
* Store notices queue B doesn't need Msg anymore; doesn't write
* Store clears Msg from the cache
* Queue A tries to read Msg
* Msg is missing from the cache
* Queue A tries to read from disk
* Msg is in the current write file and may not be on disk yet
* Crash
The problem is that the store clears Msg from the cache. We need
all messages written to the current file to remain in the cache
as we can't guarantee the data is on disk when comes the time
to read. That is, until we roll over to the next file.
The issue was that a match was wrong, instead of matching a single
location from the index, the code was matching against a list. The
error was present in the code for almost 13 years since commit
2ef30dc95e.