| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |\
| | |
| | | |
Limit x-death growth to one entry per queue
|
| | | |
| | |
| | |
| | |
| | |
| | | |
While here, wrap long lines to fit 80 columns.
References #78.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Otherwise the list can grow forever in some cases.
Fixes #78.
|
| | |\ \
| | | |
| | | | |
PR for rabbitmq/rabbitmq-server#72
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Submitted by jmcmeek on GitHub.
Fixes #72.
|
| | |\ \ \
| | |/ /
| |/| | |
PR for rabbitmq/rabbitmq-server#74
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For instance, one can use the following configuration to disable
messages related to channels:
[
{rabbit, [
{log_levels, [{channel, none}]}
]}
].
References #74.
|
| |\ \ \
| |/ / |
|
| | |\ \
| | |/
| |/| |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Take into account the size of the current read if appropriate, add an
extra byte when shrinking so next time we know how we did, and fix
comments all round.
References #69.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
While here, fix two typos.
References #69.
|
| | |/
| |
| |
| | |
...such as when we are reading backwards through a file. References #69.
|
| |\ \
| |/ |
|
| | |\ |
|
| | |/
| |
| |
| |
| |
| |
| | |
* Revoke group writing permission
* Revoke all "others" permissions
References #68.
|
| |\ \
| |/ |
|
| | |\ |
|
| | | | |
|
| | |\ \
| | |/ |
|
| | |/
| |
| |
| | |
sum. (References #67)
|
| |\ \
| |/ |
|
| | |\
| |/
|/| |
|
| | | |
|
| |\ \ |
|
| |/ /
| |
| |
| |
| |
| | |
The old way did not work if erl was not in ${ERLANG_HOME}/bin. The new way
looks like it should only work if erl is on the ${PATH} - but in fact
the Erlang VM arranges things so that is always true!
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Otherwise, in handle_dead_rabbit(), if the specified node is already
back in the cluster, "partitions" will not be emptied.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
... in pause conditions, especially if the remote node is back in the
cluster already.
This gives the node a chance to enter a pause mode. Without this,
partitions may never be fixed.
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
If the node is already back in the cluster at the time
rabbit_networking:on_node_down() is called don't remove the specified
node's listeners. Otherwise, we would loose the record from the entire
cluster, creating an inconsistency between the running listeners and the
recorded ones.
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
At least, this fixes the following crash, when the partial partition
detection tries to close the connection while RabbitMQ is stopping:
** Reason for termination ==
** {timeout,{gen_server,call,
[application_controller,
{set_env,kernel,dist_auto_connect,never}]}}
|
| |\ \ \
| |/ /
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
rabbit_node_monitor:run_outside_applications/2 gains a new argument to
indicate if the caller is willing is let a possible current outside
application process to finish before its own function can run. If this
argument is false, the current behaviour is kept: the function is not
executed.
This fixes a bug where autoheal's outside application function was not
executed if pause_if_all_down's outside application function was still
running (ie. rabbit:start() didn't return yet). The bug caused the
loser to not stop and thus the autoheal process to never complete.
Now, the autoheal outside application function waits for the
pause_if_all_down function to finish before stopping the loser.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
... and simplify the handle_msg({winner_is, _}, ...) clause.
|
| | | | |
| | | |
| | | |
| | | | |
While here, document the message flow.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Before, the leader was monitoring the losers itself (exactly like the
winner). When they were all down, it was going back to the "not_healing"
state.
Therefore, there was a possibility that the leader and winner went
out-of-sync regarding the autoheal state.
Now, the leader simply waits for a confirmation from the winner that the
autoheal process is over. If the leader is a loser too, the autoheal
state is saved in the application environment to survive the restart.
When the leader is back up, it asks the winner to possibly notify it
again.
|
| | |/ /
|/| | |
|
| |\ \ \
| |/ /
|/| | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In rabbit_node_monitor:disconnect/1, we change the "dist_auto_connect"
kernel parameter to force a disconnection and give some time to all
components to handle the subsequent "nodedown" event.
"global" doesn't handle this situation very well. With an unfortunate
sequence of messages and bad timings, this can trigger an inconsistency
in its internal state. When this happens, global:sync() never returns.
See bug 26556, comment #5 for a detailed description.
The workaround consists of a process who parses the "global" internal
state if global:sync/0 didn't return in 15 seconds. If the state
contains in-progress synchronisation older than 10 seconds, the
spawned process sends fake nodedown/nodeup events to "global" on both
inconsistent nodes so they restart their synchronisation.
This workaround will be removed once the real bugs are fixed and
"dist_auto_connect" is left untouched.
|
| |\ \
| |/ |
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the list returned by `nodes()` didn't change since last call to
`pause_minority_guard()`, return the previous state, not `ok`.
This fixes a bug where the first call to `pause_minority_guard()` could
return `pausing` but the subsequent calls would return `ok`, leading to
channels resuming the send of confirms even though the node is about to
enter pause mode.
|
| |\ \ \
| |/ / |
|
