| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Attempt to improve readability by eliminating nested folding functions.
|
| | |
|
| |\
| |
| | |
Reduce memory usage during startup
|
| | | |
|
| | |
| |
| |
| | |
https://github.com/rabbitmq/rabbitmq-common/pull/368/commits/36c9fbe59af6d6cce67fc430b333c44f30cc4c40
|
| | |
| |
| |
| |
| |
| |
| |
| | |
using spawn_link in rabbit_msg_store:build_index alters the
supervision tree such that there are unwanted side effects in
rabbit_vhost_msg_store. We monitor the spawned process so that if
there is a failure to enqueue the scan for each file, the vhost
fails to start and reports an error.
|
| | |
| |
| |
| |
| |
| | |
Make use of the new dispatch_sync function in
https://github.com/rabbitmq/rabbitmq-common/pull/368 to block only when all
workers are busy
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the case of large backlogs of persistent messages (10s of millions
of messages)
Previously we queued a job for every file with worker_pool:submit_async,
however if there are 50 million messages, this corresponds to ~79,000 files
and the same number of pending tasks in the worker pool. The mailbox for
worker_pool explodes under these circumstances, using massive amounts of
memory.
The following was helpful in zeroing in on the problem:
https://elixirforum.com/t/extremely-high-memory-usage-in-genservers/4035
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
... in case the log file was not fsync'd yet (and thus we don't see the
content yet).
This happens sometimes in Travis CI for instance.
|
| |\ \
| | |
| | | |
Wait for commits on test suite
|
| |/ /
| |
| |
| | |
Don't wait for consensus as the publish could be delayed
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
... while building `my_plugin`.
We clear ALL_DEPS_DIRS to make sure they are not recompiled when the
plugin is built. `rabbit` was previously compiled with -DTEST and if
it is recompiled because of this plugin, it will be recompiled without
-DTEST: the testsuite depends on test code so we can't allow that.
Note that we do not clear the DEPS variable: we need it to be correct
because it is used to generate `my_plugin.app` (and a RabbitMQ plugin
must depend on `rabbit`).
|
| | |
| |
| |
| |
| | |
... to explicitely inject its own feature flags, instead of relying on
actual module attributes.
|
| | |
| |
| |
| |
| |
| | |
Backends can return duplicates, sometimes for reasons outside of their
control, e.g. implicit or explicit versioning of values by the data
store they are backed by.
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
rabbitmq/fix-ff-registry-loading+improve-ff-testing
Fix feature flags registry loading + improve feature flags testing
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
... before deleting it and load the new code.
In some rare cases, the soft purge didn't work because another process
was running the old code. Thus the delete would fail.
Now, we wait for the soft purge to succeed before proceeding.
|
| |/
|
|
|
|
| |
This should be more robust than relying the caller (through a forced
exception). Way more robust considering that the latter seems to not
work at all :)
|
| | |
|
| |\
| |
| | |
rabbit_fifo: force gc when queue is empty
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Use a friendlier log message that converts bytes to megabytes.
cc @kjnilsson
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
And it uses more than a fixed limit of ~2Mb of total memory. An empty
queue should only need around ~100-200Kb of memory so this should avoid
any unnecessary full sweeps.
[#171644231]
|
| |\ \
| | |
| | | |
Introduce peer discovery retries
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When the backend returns an error, we retry.
If we fail to join discovered peers, we also retry.
Schema table sync retries are already in place so nothing
to change there.
Closes #1627.
Pair: @dumbbell.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If registration is supported, a randomized delay will be injected. It makes
sense to support it in this config, in fact, our own test suites are evidence
of that: they start all nodes in parallel.
However, this backend is used by default so even a blank single node would
then wait on a delay that serves no purpose. So we make this conditional:
if no peer nodes are configured we don't want to induce any delays.
Pair: @dumbbell.
|
| | | |
| | |
| | |
| | | |
Pair: @dumbbell.
|
| | | |
| | |
| | |
| | | |
Pair: @dumbbell.
|
| |/ /
| |
| |
| | |
Pair: @dumbbell.
|
| |/
|
|
|
| |
This is a follow-up to c503d57e884dd440aa6b830bb9835be4dd2d8f69
which was a follow-up to 12571627a6089aa7d603e92b3e35745c8d398b3e.
|
| | |
|
| |
|
|
| |
This reverts commit 1a60b43aa99bb8d97fe29a3c5266ede7678fe26e.
|
| |
|
|
|
|
|
| |
cc @michaelklishin
Signed-off-by: Philip Kuryloski <pkuryloski@pivotal.io>
(cherry picked from commit abc7b0aaad43a52d4f0473d374386b9b5b6a3936)
|
| |
|
|
|
| |
Signed-off-by: Philip Kuryloski <pkuryloski@pivotal.io>
(cherry picked from commit 955ad8d90744f352a2608ab3e305f3419df0cf0f)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This unblocks node boot, otherwise the node gets stuck on waiting for
gatherer:out/1 to return.
I am not sure why we need another work pool for boot steps and don't
just use the default work pool. After all, there is nothing else running
during node boot except the boot steps, so using the default work pool
should be sufficient.
If we do decide to create a new work pool, we will need
to stop it after boot steps complete. Obviously, we will need to first
fix this work pool which currently doesn't seem to be created. We can
see all processes for the default work pool, but we cannot find any
process for this new IMPORT_WORK_POOL.
cc @michaelklishin
Signed-off-by: Philip Kuryloski <pkuryloski@pivotal.io>
(cherry picked from commit 0f86277b06b1a27ef468dcd02f1700cc99f04bf0)
|
| |
|
|
|
|
| |
After network partition some classic queues are crashed, do not have mirrors
(cherry picked from commit 3c1b317b08870d3ca4c04c4a59b4067bf768707e)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... in `rebalance_multiple_blocked`.
The testcase wants two rebalances to happen at the same time: the first
one may succeed (but this is out of scope for this testcase) and the
second one must be aborted with `{error, rebalance_in_progress}`.
It looks like things are faster with Erlang 23 because the first
rebalance is already finished when the second starts, probably due to
internode communication being slower than rebalance (the two rebalances
are triggered from the common_test node).
This time, the testcase starts a function on the remote node which
spawns two functions in parallel to request a rebalance. Everything
being local, we increase the chance to have concurrent rebalances.
We don't know the order of execution of the two functions, so we simply
verify that one of them fails.
This is still not 100% bullet proof, but should be ok.
|
| |\
| |
| | |
Allow only one rebalance operation to happen at a time
|
| | | |
|
| |/
|
|
|
|
|
|
| |
Add code to block multiple queue rebalance operations, fix test
Allow acquiring the rebalance lock prior to calling rabbit_amqqueue:rebalance
Simplify queue rebalance code to always acquire the lock using the current process
|
| | |
|
| | |
|
| |\
| |
| | |
rabbit_fifo: change release cursor calculation
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Release cursors are taken less frequently the more messages there are on
queue. This changes how this is calculated to simply use the message
count rather than some multiple of the currently captured release
cursors. This is more consistent and doesn't depend on non snapshottable
state.
|
| | | |
|
| | | |
|
| |/ |
|
