4.3.0.RC2

Changes between 4.2.2 and 4.3.0.RC2

This is a release candidate for 4.3.0, a maintenance release that includes 2 new features and bug fix. This release is backward-compatible with 4.2.2.

Support Micrometer

The Java Client supports Micrometer through its MicrometerMetricsCollector implementation of MetricsCollector. Micrometer is an instrumentation facade, which supports popular metrics backends (Atlas, Graphite, Ganglia, Datadog, JMX, etc). Note Micrometer requires Java 8 or more. The Java Client 4.3.x still supports Java 6, but Micrometer support isn't usable on Java 6 and Java 7.

GitHub issue: #313

Make auto-recovery retry interval calculation pluggable

The RecoveryDelayHandler interface has been introduced to calculate the retry interval between each connection recovery attempt. The default strategy is still the same: a constant interval (5 seconds by default). The ExponentialBackoffDelayHandler implementation can be used to have an exponential retry interval.

Thanks to @vikinghawk for this contribution.

GitHub issue: #308

Handle several buffer underflow results in SslEngineByteBufferInputStream

Thanks to @dimas for this fix.

GitHub issue: #317

4.3.0.RC1

Changes between 4.2.2 and 4.3.0.RC1

This is a release candidate for 4.3.0.RC1, a maintenance release that includes 2 new features. This release is backward-compatible with 4.2.2.

Support Micrometer

The Java Client supports Micrometer through its MicrometerMetricsCollector implementation of MetricsCollector. Micrometer is an instrumentation facade, which supports popular metrics backends (Atlas, Graphite, Ganglia, Datadog, JMX, etc). Note Micrometer requires Java 8 or more. The Java Client 4.3.x still supports Java 6, but Micrometer support isn't usable on Java 6 and Java 7.

GitHub issue: #313

Make auto-recovery retry interval calculation pluggable

The RecoveryDelayHandler interface has been introduced to calculate the retry interval between each connection recovery attempt. The default strategy is still the same: a constant interval (5 seconds by default). The ExponentialBackoffDelayHandler implementation can be used to have an exponential retry interval.

Thanks to @vikinghawk for this contribution.

GitHub issue: #308

5.0.0

Changes between 4.x.x and 5.0.0

This major release requires Java 8. It introduces several new features and lambda-oriented methods for common use cases. It has also a few breaking changes that should have minor or no impact on most applications.

Users running Java 8 or Java 9 are encouraged to upgrade to this release.

Java 8 is Now Required

The client no longer supports JDK 6 and 7. JDK 8 is now required to both build and run (use) this library. Starting with the 5.0 release, there are Java 8-specific features in the API (e.g. lambdas).

Because of the Java 8 requirement, this client only supports Android 7.0 or later. If support
for earlier Android versions is desired, use the 4.x releases instead.

GitHub issue: #304.

Lambda-oriented API for Consumers

Channel has now basicConsume methods with functional interfaces as arguments, making it possible to use lambdas in the method call. Note that not all the methods of Consumer are supported, we retained only the "essential" ones: when a message is delivered, when the consumer is cancelled, and when the channel/connection is closed. Simple or straightforward consumers will benefit from these lambda-based methods, more advanced consumers can still implement all the callbacks they need in the Consumer interface. Have a look at the test class for examples of usage.

GitHub issue: #247

Make it possible to use lambdas instead of *Listener objects

It's now possible to use lambdas for the following listeners: ConfirmListener, ReturnListener, and BlockedListener, thanks to new functional interfaces and new methods in Connection and in Channel. The original *Listener methods and interfaces are still around though. Have a look at the test class for examples of usage.

GitHub issue: #246

Add an asynchronous method which returns a CompletableFuture

Channel has a new method to handle AMQP asynchronous calls:

CompletableFuture<Command> asyncCompletableRpc(Method method) throws IOException;

This method is a foundation to build so-called reactive applications, thanks to the returned CompletableFuture. It's on purpose quite low-level (using the Method type as an argument).

GitHub issue: #215

Introduce SslContextFactory interface to create SSLContext instances

ConnectionFactory has now a new SslContextFactory property to create SSLContext contexts for connections. The connection name (part of the connection properties) can be used to conditionally create the SSLContext instance for the connection. This way the same ConnectionFactory instance can create connections with different certificates but sharing the same resources (e.g. IO threads when using NIO). This features introduces a breaking change: the FrameHandlerFactory#create method has now an extra connectionName String argument. This shouldn't impact applications as FrameHandlerFactory is an interface meant to be used internally. Note all the ConnectionFactory#useSslProtocol methods still work the same way, they use the SslContextFactory interface under the covers.

GitHub issue: #241

Remove QueueingConsumer from RpcServer

RpcServer was using QueueingConsumer internally, which has been removed in this release. Depending on the use of RpcServer, this can imply breaking changes (see below). The overall behavior of RpcServer shouldn't change, as it's using now its own private version of a QueueingConsumer.

GitHub issue: #221

Replace AssertionErrors with more appropriate exceptions

AssertionErrors have been replaced by more appropriate, less dramatic exceptions classes (e.g. IllegalArgumentException). AssertionsErrors were used in a few places of internal APIs, this change shouldn't impact application code.

GitHub issue: #239

Channel implements AutoCloseable

Channel can now be used inside try-with-resources statements. The JVM will automatically close the Channel once the program exits from a try-with-resources statement.

Thanks to Venil Noronha for this contribution.

GitHub issue: #258

Removal of deprecated classes and methods

The following deprecated classes and interfaces have been removed: QueueingConsumer, NullTrustManager, FlowListener, and SingleShotLinearTimer. Please see the implications below.

GitHub issue: #212

Breaking changes

Connection

A new method has been introduced, addBlockedListener(BlockedCallback, UnblockedCallback). This is a concern only if you implement your own Connection. If you only use Connection in your application, the rest of the API hasn't changed.

Channel

New methods have been introduced: addReturnListener(ReturnCallback), addConfirmListener(ConfirmCallback, ConfirmCallback), asyncCompletableRpc(Method), and "lambda-enabled" basicConsume methods. This is a concern only if you implement your own Channel. If you only use Channel in your application, the rest of the API hasn't changed.

RpcServer

RpcServer doesn't rely anymore on QueueingConsumer, which has been removed. If your RpcServer implementation relies on QueueingConsumer.Delivery, use RpcServer.Delivery instead (it has the same API). If you override setupConsumer to create the consumer, you need now to create an implementation of RpcServer.RpcConsumer in this method.

FrameHandlerFactory

FrameHandlerFactory#create has an extra connectionName String parameter. Note this interface isn't meant to be used in applications, so this change shouldn't impact application code.

Removal of AssertionError usages

AssertionsErrors were used in a few places of internal APIs (e.g. BlockingCell), not meant to be used by applications. Nevertheless, if you use those, have a look at the code changes in the GitHub issue #239.

Removal of QueueuingConsumer

QueueingConsumer had been originally introduced to allow applications to overcome a limitation in the way Connection managed threads and consumer dispatching. The threading behavior of Connection and Channel has been changed since then, making QueueingConsumer less relevant. If blocking behavior is needed, applications can use DefaultConsumer and a JDK BlockingQueue.

Removal of NullTrustManager

Use TrustEverythingTrustManager instead, it has the same behavior, but a more meaningful name.

Removal of FlowListener

Channel flow events have been superseded by TCP back pressure. Corresponding methods have been removed from the Channel and ExceptionHandler interfaces, so implementations of those interfaces need to remove them as well (most likely ExceptionHandler implementations, Channel not being an interface implemented in applications).

4.2.2

Changes between 4.2.1 and 4.2.2

This is a maintenance release that includes a bug fix in TLS when using NIO mode and a bug fix in the RpcClient. It's backward compatible with the 4.x.x series and users of those series are encouraged to use this release.

Thanks to Dmitry Andrianov for his contribution on this release.

Always flip ByteBuffer when consuming large messages on TLS

GitHub issue: #307

Check for null blocker in RpcClient

GitHub issue: #306

5.0.0.RC1

5.0.0.RC1

Changes between 4.x.x and 5.0.0

Java 8 is now a pre-requisite

The client neither supports Java 6 anymore nor Java 7. The client pre-requisite is now Java 8 and it uses some of the Java 8 features in its API (e.g. lambdas).

GitHub issue: #304

Lambda-oriented methods for consuming messages

Channel has now basicConsume methods with functional interfaces as arguments, making it possible to use lambdas in the method call. Note that not all the methods of Consumer are supported, we retained only the "essential" ones: when a message is delivered, when the consumer is cancelled, and when the channel/connection is closed. Simple or straightforward consumers will benefit from these lambda-based methods, more advanced consumers can still implement all the callbacks they need in the Consumer interface. Have a look at the test class for examples of usage.

GitHub issue: #247

Make it possible to use lambdas instead of *Listener objects

It's now possible to use lambdas for the following listeners: ConfirmListener, ReturnListener, and BlockedListener, thanks to new functional interfaces and new methods in Connection and in Channel. The original *Listener methods and interfaces are still around though. Have a look at the test class for examples of usage.

GitHub issue: #246

Add an asynchronous method which returns a CompletableFuture

Channel has a new method to handle AMQP asynchronous calls:

CompletableFuture<Command> asyncCompletableRpc(Method method) throws IOException;

This method is a foundation to build so-called reactive applications, thanks to the returned CompletableFuture. It's on purpose quite low-level (using the Method type as an argument).

GitHub issue: #215

Introduce SslContextFactory interface to create SSLContext instances

ConnectionFactory has now a new SslContextFactory property to create SSLContext contexts for connections. The connection name (part of the connection properties) can be used to conditionally create the SSLContext instance for the connection. This way the same ConnectionFactory instance can create connections with different certificates but sharing the same resources (e.g. IO threads when using NIO). This features introduces a breaking change: the FrameHandlerFactory#create method has now an extra connectionName String argument. This shouldn't impact applications as FrameHandlerFactory is an interface meant to be used internally. Note all the ConnectionFactory#useSslProtocol methods still work the same way, they use the SslContextFactory interface under the covers.

GitHub issue: #241

Remove QueueingConsumer from RpcServer

RpcServer was using QueueingConsumer internally, which has been removed in this release. Depending on the use of RpcServer, this can imply breaking changes (see below). The overall behavior of RpcServer shouldn't change, as it's using now its own private version of a QueueingConsumer.

GitHub issue: #221

Replace AssertionErrors with more appropriate exceptions

AssertionErrors have been replaced by more appropriate, less dramatic exceptions classes (e.g. IllegalArgumentException). AssertionsErrors were used in a few places of internal APIs, this change shouldn't impact application code.

GitHub issue: #239

Channel implements AutoCloseable

Channel can now be used inside try-with-resources statements. The JVM will automatically close the Channel once the program exits from a try-with-resources statement.

Thanks to Venil Noronha for this contribution.

GitHub issue: #258

Removal of deprecated classes and methods

The following deprecated classes and interfaces have been removed: QueueingConsumer, NullTrustManager, FlowListener, and SingleShotLinearTimer. Please see the implications below.

GitHub issue: #212

Breaking changes

Connection

A new method has been introduced, addBlockedListener(BlockedCallback, UnblockedCallback). This is a concern only if you implement your own Connection. If you only use Connection in your application, the rest of the API hasn't changed.

Channel

New methods have been introduced: addReturnListener(ReturnCallback), addConfirmListener(ConfirmCallback, ConfirmCallback), asyncCompletableRpc(Method), and "lambda-enabled" basicConsume methods. This is a concern only if you implement your own Channel. If you only use Channel in your application, the rest of the API hasn't changed.

RpcServer

RpcServer doesn't rely anymore on QueueingConsumer, which has been removed. If your RpcServer implementation relies on QueueingConsumer.Delivery, use RpcServer.Delivery instead (it has the same API). If you override setupConsumer to create the consumer, you need now to create an implementation of RpcServer.RpcConsumer in this method.

FrameHandlerFactory

FrameHandlerFactory#create has an extra connectionName String parameter. Note this interface isn't meant to be used in applications, so this change shouldn't impact application code.

Removal of AssertionError usages

AssertionsErrors were used in a few places of internal APIs (e.g. BlockingCell), not meant to be used by applications. Nevertheless, if you use those, have a look at the code changes in the GitHub issue #239.

Removal of QueueuingConsumer

QueueingConsumer had been originally introduced to allow applications to overcome a limitation in the way Connection managed threads and consumer dispatching. The threading behavior of Connection and Channel has been changed since then, making QueueingConsumer less relevant. If blocking behavior is needed, applications can use DefaultConsumer and a JDK BlockingQueue.

Removal of NullTrustManager

Use TrustEverythingTrustManager instead, it has the same behavior, but a more meaningful name.

Removal of FlowListener

Channel flow events have been superseded by TCP back pressure. Corresponding methods have been removed from the Channel and ExceptionHandler interfaces, so implementations of those interfaces need to remove them as well (most likely ExceptionHandler implementations, Channel not being an interface implemented in applications).

4.2.1

Changes between 4.2.0 and 4.2.1

This is a maintenance release that includes a bug fix about TLS settings. It's backward compatible with the 4.x.x series and users of those series are encouraged to use this release.

SSLContext is always set up to default value when using ConnectionFactory#setUri

Calling ConnectionFactory#setUri would always set the SSLContext property to the default value (which trusts all servers). The SSLContext could be set up after the call to setUri, but a warning would nevertheless be logged. setUri now sets the SSLContext to the default value only if it hasn't been set before.

GitHub issue: #298

4.2.1.RC1

Changes between 4.2.0 and 4.2.1.RC1

This is a release candidate for 4.2.1, a maintenance release that includes a bug fix about TLS settings. This release is backward-compatible with 4.2.0.

SSLContext is always set up to default value when using ConnectionFactory#setUri

Calling ConnectionFactory#setUri would always set the SSLContext property to the default value (which trusts all servers). The SSLContext could be set up after the call to setUri, but a warning would nevertheless be logged. setUri now sets the SSLContext to the default value only if it hasn't been set before.

GitHub issue: #298

4.2.0

Changes between 4.1.1 and 4.2.0

This is a maintenance release that includes 2 new features. It's backward compatible with 4.1.x. Users of the 4.0.x and 4.1.x series are encouraged to use this release.

Introduce SSLEngine configuration hook for NIO

It's now possible to configure the SSLEngine used for a secured connection just after its creation. This can be useful to pass in SSLParameters to configure e.g. server's SNI hosts. The new interface is SslEngineConfigurator and an instance can be set in NioParams.

GitHub issue: #274

Add option to ensure RPC reply is for the current request

During node failover and connection recovery, a timed out RPC reply can come back while a second RPC request is waiting. This can cause ClassCastExceptions. It's now possible to enable the ConnectionFactory#channelShouldCheckRpcResponseType to perform a "best-effort" check of RPC replies and ignore non-compatible replies. The default value of the flag is false (no check by default).

Thanks to @vikinghawk for this contribution.

GitHub issue: #290

4.2.0.RC1

Changes between 4.1.1 and 4.2.0.RC1

This is a release candidate for 4.2.0, a maintenance release that includes 2 new features. This release is backward-compatible with 4.1.1.

Introduce SSLEngine configuration hook for NIO

It's now possible to configure the SSLEngine used for a secured connection just after its creation. This can be useful to pass in SSLParameters to configure e.g. server's SNI hosts. The new interface is SslEngineConfigurator and an instance can be set in NioParams.

GitHub issue: #274

Add option to ensure RPC reply is for the current request

During node failover and connection recovery, a timed out RPC reply can come back while a second RPC request is waiting. This can cause ClassCastExceptions. It's now possible to enable the ConnectionFactory#channelShouldCheckRpcResponseType to perform a "best-effort" check of RPC replies and ignore non-compatible replies. The default value of the flag is false (no check by default).

Thanks to @vikinghawk for this contribution.

GitHub issue: #290

4.1.1

Changes between 4.1.0 and 4.1.1

This is a maintenance release that includes bug fixes and a small improvement in the RpcServer class. It's backward compatible with 4.1.0.

Handle TimeoutException on connection creation

When several addresses are provided to the ConnectionFactory and when an address throws a TimeoutException on connection creation, the client wouldn't try the next addresses and throw an exception. Now the client tries to connect to the next address even on a TimeoutException.

GitHub issue: #262

Let reply properties be updated in RpcServer subclasses

The properties of a response message can now be updated with the preprocessReplyProperties and postprocessReplyProperties methods that are called around the handleCall method.

GitHub issue: #271

Remove e2e bindings for auto-delete exchanges

It was possible to have abandoned e2e bindings in the recordedBindings. This caused a channel error during recovery and caused remaining recovery items to fail as well.

Thanks to vikinghawk for this contribution.

GitHub PR: #281

basicCancel and basicConsume honor RPC timeout

The 2 methods basicCancel and basicConsume now use the channel RPC timeout (they used to not use any timeout at all).

Thanks to vikinghawk for this contribution.

GitHub PR: #278

Close SocketChannel correctly in NIO mode

The SocketChannel wasn't properly closed in NIO mode. The connections would show up a few dozens of seconds in the management web UI before being closed automatically by the server.

GitHub issue: #284