TL;DR

HotBunnies 2.0.0.pre12 is released to rubygems.org.

This release is a development milestone. 2.0 focuses on usability and introduces a couple of major API improvements and features.

2.0 should be production ready from the stability perspective but has breaking API changes. Please consult the change log below before considering upgrading.

Changes Between 2.0.0.pre11 and 2.0.0.pre12

Make HotBunnies::Queue#subscribe Respect All Options

Make HotBunnies::Queue#subscribe respect all options it used to accept before pre11 again.

exchange.unbind Support

HotBunnies::Exchange#unbind is now provided to compliment HotBunnies::Exchange#bind.

Safe[r] basic.ack, basic.nack and basic.reject implementation

Previously if a channel was recovered (reopened) by automatic connection recovery before a message was acknowledged or rejected, it would cause any operation on the channel that uses delivery tags to fail and cause the channel to be closed.

To avoid this issue, every channel keeps a counter of how many times it has been reopened and marks delivery tags with them. Using a stale tag to ack or reject a message will produce no method sent to RabbitMQ. Note that unacknowledged messages will be requeued by RabbitMQ when connection goes down anyway.

This involves an API change: HotBunnies::Headers#delivery_tag is now and instance of a class that responds to #to_i and is accepted by HotBunnies::Channel#ack and related methods.

Integers are still accepted by the same methods.

Plans for 2.0.0 Final

There is still a few things we need to do before HotBunnies 2.0 can be declared complete:

• Further test automatic network failure recovery
• Make TLS support more configurable, ideally with the same API as Bunny 0.10
• Add logging
• Review API reference documentation

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

Bunny 0.10.4 is released to rubygems.org.

This is a usability improvements release that is completely backwards compatible with 0.10.x.

We encourage all Bunny users to upgrade to it.

Changes between Bunny 0.10.3 and 0.10.4

Default Paths for TLS/SSL CA’s on All OS’es

Bunny now uses OpenSSL to detect default TLS/SSL CA’s paths, extending this feature to OS’es other than Linux.

Contributed by Jingwen Owen Ou.

Changes between Bunny 0.10.2 and 0.10.3

Default Paths for TLS/SSL CA’s on Linux

Bunny now will use the following TLS/SSL CA’s paths on Linux by default:

• /etc/ssl/certs/ca-certificates.crt on Ubuntu/Debian
• /etc/ssl/certs/ca-bundle.crt on Amazon Linux
• /etc/ssl/ca-bundle.pem on OpenSUSE
• /etc/pki/tls/certs/ca-bundle.crt on Fedora/RHEL

and will log a warning if no CA files are available via default paths or :tls_ca_certificates.

Contributed by Carl Hörberg.

Full change log can be found on GitHub.

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

Bunny 0.10.3 is released to rubygems.org.

This is a usability improvements release that is completely backwards compatible with 0.10.x.

We encourage all Bunny users to upgrade to it.

Changes between Bunny 0.10.2 and 0.10.3

Default Paths for TLS/SSL CA’s on Linux

Bunny now will use the following TLS/SSL CA’s paths on Linux by default:

• /etc/ssl/certs/ca-certificates.crt on Ubuntu/Debian
• /etc/ssl/certs/ca-bundle.crt on Amazon Linux
• /etc/ssl/ca-bundle.pem on OpenSUSE
• /etc/pki/tls/certs/ca-bundle.crt on Fedora/RHEL

and will log a warning if no CA files are available via default paths or :tls_ca_certificates.

Contributed by Carl Hörberg.

Full change log can be found on GitHub.

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

HotBunnies 2.0.0.pre11 is released to rubygems.org.

This release is a development milestone. 2.0 focuses on usability and introduces a couple of major API improvements and features.

2.0 should be production ready from the stability perspective but has breaking API changes. Please consult the change log below before considering upgrading.

Changes Between 2.0.0.pre10 and 2.0.0.pre11

Consumer Work Pool Changes

HotBunnies 1.x used to maintain a separate executor (thread pool) per non-blocking consumer. This is not optimal and reimplements the wheel RabbitMQ Java client already has invented: it dispatches consumer methods in a thread pool maintained by every connection.

Instead of maintaining its own executor, HotBunnies now relies on the Java client to do the job.

It is still possible to override the executor when opening a connection by providing an executor factory (any Ruby callable):

1
2
3

HotBunnies.connect(:executor_factory => Proc.new {
  HotBunnies::ThreadPools.fixed_of_size(16)
})

It has to be a factory to make sure we can allocate a new pool upon connection recovery, since JVM executors cannot be cloned or restarted.

By default HotBunnies will rely on the default RabbitMQ Java client’s executor service, which has a fixed size of 5 threads.

Plans for 2.0.0 Final

There is still a few things we need to do before HotBunnies 2.0 can be declared complete:

• Further test automatic network failure recovery
• Make TLS support more configurable, ideally with the same API as Bunny 0.10
• Add logging
• API reference documentation

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

HotBunnies 2.0.0.pre10 is released to rubygems.org.

This release is a development milestone. 2.0 focuses on usability and introduces a couple of major API improvements and features.

2.0 should be production ready from the stability perspective but has breaking API changes. Please consult the change log below before considering upgrading.

Changes Between 2.0.0.pre8 and 2.0.0.pre10

Automatic Connection Recovery

HotBunnies now supports automatic connection recovery from a network outage, similar to the version in Bunny.

It recovers

• Connections
• Shutdown hooks
• Channels
• Exchanges, queues and bindings declared on the connection
• Consumers

and can be disabled by setting :automatically_recover connection option to false.

This is the first version that works correctly in many common cases, but we don’t consider it to be 100% ready to recommend yet.

Plans for 2.0.0 Final

There is still a few things we need to do before HotBunnies 2.0 can be declared complete:

• Further test and improve automatic network failure recovery
• Make TLS support more configurable, ideally with the same API as Bunny 0.9
• Add logging
• API reference documentation

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

Bunny 0.10.2 is released to rubygems.org.

This is a bug fix release that is completely backwards compatible with 0.10.x.

We encourage all Bunny users to upgrade to it.

Changes between Bunny 0.10.1 and 0.10.2

Consumers Can Be Re-Registered From Bunny::Consumer#handle_cancellation

It is now possible to re-register a consumer (and use any other synchronous methods) from Bunny::Consumer#handle_cancellation, which is now invoked in the channel’s thread pool.

Bunny::Session#close Fixed for Single Threaded Connections

Bunny::Session#close with single threaded connections no longer fails with a nil pointer exception.

Full change log can be found on GitHub.

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

Bunny 0.10.1 is released to rubygems.org.

This is a bug fix release that is completely backwards compatible with 0.10.x.

We encourage all Bunny users to upgrade to it.

Changes between Bunny 0.10.0 and 0.10.1

Fixes for Abnormally Slow Bunny::Connection#close on JRuby

Bunny::Connection#close on JRuby sometimes could enter a waiting state [on a native NIO/kqueue method] that lasted up to over 10 seconds.

This severely affected test suite run times.

Full change log can be found on GitHub.

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

Bunny 0.10.0 is released to rubygems.org.

This is a usability improvement release that is one breaking API change with 0.9.x.

We encourage all Bunny users to upgrade to it.

Changes between Bunny 0.9.8 and 0.10.0

Safe[r] basic.ack, basic.nack and basic.reject implementation

Previously if a channel was recovered (reopened) by automatic connection recovery before a message was acknowledged or rejected, it would cause any operation on the channel that uses delivery tags to fail and cause the channel to be closed.

To avoid this issue, every channel keeps a counter of how many times it has been reopened and marks delivery tags with them. Using a stale tag to ack or reject a message will produce no method sent to RabbitMQ. Note that unacknowledged messages will be requeued by RabbitMQ when connection goes down anyway.

This involves an API change: Bunny::DeliveryMetadata#delivery_tag is now an instance of a class that responds to #tag and #to_i and is accepted by Bunny::Channel#ack and related methods.

Integers are still accepted by the same methods.

Full change log can be found on GitHub.

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

Bunny 0.9.8 is released to rubygems.org.

This is a usability improvement release that is completely backwards compatible with 0.9.0.

We encourage all Bunny users to upgrade to it.

Changes between Bunny 0.9.7 and 0.9.8

Exclusivity Violation for Consumers Now Raises a Reasonable Exception

When a second consumer is registered for the same queue on different channels, a reasonable exception (Bunny::AccessRefused) will be raised.

Full change log can be found on GitHub.

Michael on behalf of the Ruby RabbitMQ Clients Team

TL;DR

Bunny 0.9.7 is released to rubygems.org.

This is a bug fix release that is completely backwards compatible with 0.9.0.

We encourage all Bunny users to upgrade to it.

Changes between Bunny 0.9.6 and 0.9.7

Reentrant Mutex Implementation

Bunny now allows mutex impl to be configurable, uses reentrant Monitor by default.

Non-reentrant mutexes is a major PITA and may affect code that uses Bunny.

Avg. publishing throughput with Monitor drops slightly from 5.73 Khz to 5.49 Khz (about 4% decrease), which is reasonable for Bunny.

Apps that need these 4% can configure what mutex implementation is used on per-connection basis.

Changes between Bunny 0.9.5 and 0.9.6

Eliminated Race Condition in Bunny::Session#close

Bunny::Session#close had a race condition that caused (non-deterministic) exceptions when connection transport was closed before connection reader loop was guaranteed to have stopped.

Changes between Bunny 0.9.4 and 0.9.5

connection.close Raises Exceptions on Connection Thread

Connection-level exceptions (including when a connection is closed via management UI or rabbitmqctl) will now be raised on the connection thread so they

• can be handled by applications
• do not start connection recovery, which may be uncalled for

Full change log can be found on GitHub.

Michael on behalf of the Ruby RabbitMQ Clients Team