Skip to content

Instantly share code, notes, and snippets.

We wanted flying cars, instead we got GitHub status

Michael Klishin michaelklishin

We wanted flying cars, instead we got GitHub status
Block or report user

Report or block michaelklishin

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
michaelklishin /
Last active Nov 15, 2019 — forked from lukebakken/
How to Run a Hot RabbitMQ Standby with Federated Exchanges


It is often desired to have a hot standby RabbitMQ node or cluster in a remote location so that a data centre failure can be recovered from in a reasonable amount of time by redeploying/switching applications to use the standby.

A combination of existing RabbitMQ features, exchange federation and queue message TTL (or queue length limit) can be used to achieve this. Such standby would have N minutes or hours of data available for [re-]consumption by applications.

It involves a few steps:


The RabbitMQ team has been looking at the performance differences between the latest RMQ releases. After benchmarking multiple RabbitMQ version/Erlang version/build environment permutations, we have some findings to share.

The new management plugin and stats emission/collection implementation in RabbitMQ 3.6.7 produces a slight drop in performance in some workloads.

Another finding suggests that RabbitMQ packages compiled in Erlang R16B03 (such as the 3.6.x releases produced by our team) will have a minor throughput drop when running on Erlang 20.x. Packages built on Erlang 19.x.x and ran on Erlang 20.x.x showed no such difference.


Dear RabbitMQ community,

We have an update on Erlang/OTP 20 and RabbitMQ compatibility.

First, let's clarify when OTP 20 support will be available: RabbitMQ versions before 3.6.11 will not work correctly with OTP-20.

What's the risk of upgrading from 19.x to 20 on an unsupported version? When upgrading from OTP-19.x(or earlier) to OTP-20 all the persistent data will be permanently lost!


RabbitMQ team is proud to announce that starting from the version 3.7.0 RabbitMQ will come with the new command line tools, known as rabbitmqctl.

The reasoning behind this change is that in previous versions rabbitmqctl was deeply integrated into server code, which made it hard to implement new commands, extend and modify existing commands.

The tools is written on [Elixir][elixir] programming language. This will make it easier for people new to erlang to start extending the tools. Although after built, the tools don't require Elixir to be installed.


Keybase proof

I hereby claim:

  • I am michaelklishin on github.
  • I am michaelklishin ( on keybase.
  • I have a public key whose fingerprint is 07CF 80D8 1AE4 711A FF3F 045A E80E DCFA 0CDB 21EE

To claim this, I am signing this object:

View Installing RabbitMQ 3.6.3+ Debian package on Ubuntu 12.04
+# Add Debian Wheezy backports repository to obtain init-system-helpers
+gpg --keyserver --recv-key 7638D0442B90D010
+gpg -a --export 7638D0442B90D010 | sudo apt-key add -
+echo 'deb wheezy-backports main' | sudo tee /etc/apt/sources.list.d/wheezy_backports.list
+# Add Erlang Solutions repository to obtain esl-erlang
+wget -O- | sudo apt-key add -
+echo 'deb wheezy contrib' | sudo tee /etc/apt/sources.list.d/esl.list
+sudo apt-get update
View Publisher.cs
using System;
using System.Threading;
using RabbitMQ.Client;
using RabbitMQ.Client.Framing;
namespace rabbitPublisher
class rabbitPublisher
public static byte[] TestMessage = new byte[1024];
View gist:932ec59c42c1c9c2ceee
{ssl_options, [{ciphers, ["ECDHE-ECDSA-AES256-SHA384","ECDHE-RSA-AES256-SHA384",
View gist:f6a07d13f33232c985cb
{rabbit, [
{tcp_listeners, [{"", 5672}]}
View rabbitmq.config
{ssl, [{versions, ['tlsv1.2', 'tlsv1.1', tlsv1]},
{ciphers, [{dhe_rsa,aes_256_cbc,sha}]}
{rabbit, [
{ssl_listeners, [5672]},
{tcp_listeners, []},
{ssl_options, [{cacertfile,"/path/to/cacert.pem"},
You can’t perform that action at this time.