| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
Syslog backend is no longer configured via lager handler,
facility and identity options are in the syslog application
config now.
|
| | |
|
| |
|
|
|
| |
Configure the syslog application directly instead of relying on
rabbit_lager module.
|
| | |
|
| |\
| |
| | |
Do not set table-wide and partial locks when deleting bindings.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Dirty deletes are faster and idempotent, which means
that it can be run in transaction as long as it's locked
in the begining of transaction, which is done in
`lock_resource`.
Speed improvement is aquired by not setting record locks
for each record, since we already have a record lock
Addresses #1566
[#156352963]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of locking entire table we can use a custom global lock on
the affected resource (source or destination).
This can improve performance when multiple records deleted at the
same time, for example when connection with exclusive queues closes.
Resource lock also aquired when adding or removing a binding, so it
won't conflict with bulk removal.
Addresses #1566
[#156352963]
|
| |\ \
| | |
| | | |
Hard cap for maximum priorities
|
| | | |
| | |
| | |
| | | |
Part of #1590.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
References #1590.
[#157380396]
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit f5aa1fbe043395806d9b9ed8780892924431466c.
This feature wasn't available in the original implementation for a reason:
policies are dynamic and can change after a queue's been declared. However,
queue priorities are (at least currently) set in stone from the moment of
queue creation. This was mentioned in the docs but not explicitly enough and got overlooked.
Credit for the [re-]discovery goes to @acogoluegnes :)
References #1590.
[#157380396]
|
| | | |
| | |
| | |
| | | |
Part of #1590.
|
| | | |
| | |
| | |
| | | |
Part of #1590.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is the value we advertise in the docs
and it should be enforced to avoid process explosion
e.g. when an overflow value is provided.
Part of #1590.
[#157380396]
|
| |/ /
| |
| |
| |
| |
| | |
References #1590.
[#157380396]
|
| |\ \
| |/
|/| |
Change channel_max default to 2047
|
| | |
| |
| |
| |
| | |
Since channel 0 exists on every connection for negotiation and error
communication. 655365 = (1 << 16) - 1, so 2047 = (1 << 11) - 1.
|
| |/
|
|
| |
Closes #1593.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
promoted
There can be a race condition when a master queue is briefly restarted.
If master rejoins a stopping GM it is also stopped.
In that case it sould be sefier to stop the slave and let another be
promoted and also stopped. If master return it will either rejoin
slaves or create a new GM.
|
| |\
| |
| | |
One more place where a map definition must be converted to proplist before validation
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
validation
Fixes rabbitmq/rabbitmq-management#565.
References rabbitmq/rabbitmq-server#1493, rabbitmq/rabbitmq-federation#70,
rabbitmq/rabbitmq-shovel#38, rabbitmq/rabbitmq-federation#73.
[#157045132]
|
| |\ \
| |/
|/| |
Policy key to not promote unsynchronised queues.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This new policy controls if unsynchronised slaves should be promoted
after master crash. If set to `when-synced`, unsynchronised slaves
will not be promoted, keeping the state of the queue, but making it
unavailable until master node returns.
This change is supposed to make the cluster shutdown safier,
because queues can fail or be killed on shutdown.
The queues without master will be available from the management UI
and can be deleted and redeclared, but will not automatically loose
messages.
Trying to declare or passively declare the queue will result in a
timeout error. Same way as if the master was gracefully stopped with
ha-promote-on-shutdown: when-synced
[#156811690]
|
| |\ \
| | |
| | | |
Handle bump_reduce_memory_use non-true case
|
| | | |
| | |
| | |
| | | |
Fixes #1582
|
| |/ /
| |
| |
| | |
[ci skip]
|
| |\ \
| |/
|/| |
Use rabbit_net:hostname
|
| |/
|
|
| |
This will take into account error conditions which will default to the value returned by inet:gethostname()
|
| |\
| |
| | |
Make it possible for peer discovery backends to provide their own RSD range
|
| |/
|
|
| |
References rabbitmq/rabbitmq-peer-discovery-k8s#23.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
rabbit_parameter_validation: support maps in proplist validator
|
| |/
|
|
|
| |
Part of rabbitmq/rabbitmq-federation#73, references rabbitmq/rabbitmq-federation#70,
rabbitmq/rabbitmq-federation#67.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | |\
|/ /
| |
| | |
reduce-mnesia-contention-when-nodes-restart-master
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise, if there is more than 1 node that runs
rabbit_node_monitor:on_node_down/1, there will be
`{aborted,no_transaction` errors.
{{aborted,no_transaction},
[{mnesia,abort,1,[{file,"mnesia.erl"},{line,351}]},
{rabbit_exchange_type_topic,'-remove_bindings/3-lc$^0/1-0-',1,
[{file,"src/rabbit_exchange_type_topic.erl"},
{line,78}]},
{rabbit_exchange_type_topic,remove_bindings,3,
[{file,"src/rabbit_exchange_type_topic.erl"},
{line,78}]},
{rabbit_binding,x_callback,4,[{file,"src/rabbit_binding.erl"},{line,570}]},
{rabbit_binding,'-process_deletions/2-fun-0-',2,
[{file,"src/rabbit_binding.erl"},{line,547}]},
{dict,map_bucket,2,[{file,"dict.erl"},{line,481}]},
{dict,map_bkt_list,2,[{file,"dict.erl"},{line,477}]},
{dict,map_bkt_list,2,[{file,"dict.erl"},{line,477}]}]}
Partner-in-crime: @essen
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rather than calling `rabbit_core_metrics:delete_queue/1` for every
queue, collect all deleted queues and delete all their metrics in a
single operation.
We don't use a single Mnesia transaction to delete all objects related
to a queue and this may be a problem, but we haven't run this version of
the code long enough to know for sure. What should we be looking out for
@michaelklishin?
For initial context, see #1513
Partner-in-crime: @essen
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When many queues are being deleted, we believe that it's faster to have
fewer Mnesia transactions and therefore group 10 queue deletions into a
single Mnesia transaction. This number (10) is arbitrary, we didn't try
with a different number. Creating 1 Mnesia transaction for every queue
deletion feels too many transaction, and having a single Mnesia
transaction for all queue deletions is too few transactions. This felt
like a sensible option.
We cannot determine if this is a good change because
rabbit_core_metrics:queue_deleted/1 takes the most time and obscures all
observations. According to qcachegrind,
rabbit_misc:execute_mnesia_transaction/1 takes 1.8s while
rabbit_core_metrics:queue_deleted/1 takes 132s out of which ets:select/2
takes 131s.
How can we optimise rabbit_core_metrics:queue_deleted/1 ? We are
thinking that rather than calling ets:select/2 twice for every queue, we
should call it twice for all queues that need to be deleted. We don't
know whether this is possible. Alternatively, we might look into
ets:first/1 & ets:next/2 to iterate over the entire table ONCE with all
the queues that have been deleted. Thoughts @dcorbacho @michaelklishin ?
For initial context, see #1513
Partner-in-crime: @essen
|
| | | |
|
