Hi everyone, some time ago Justin Ross introduced the idea of an
imperative messaging API that could be implemented in various languages
and live alongside our existing AMQP clients like Qpid JMS and the
various Proton-based reactive style clients that we offer.
The goals of the imperative API are to allow for development of clients
that utilize modern language features to offer a mixture of asynchronous
programming with options for blocking as needed within the application.
These new clients would be client only implementations no server
functionality is offered.
Here I am introducing an initial Java-based implementation of the
proposal imperative API that uses Java Futures to back the asynchronous
APIs allowing for blocking if needed but also for pipelined operation
Within this implementation I’ve provided support for things like the
asynchronous sends and disposition tracking defined in the imperative
API presently as well as support for transactions and large message
streamed send and receive. Future work remains around client
reconnection and other possible API extensions.
As a reminder, the imperative API and this Java implementation remain
subject to change. We want to gather feedback from the community and
make any important API changes that are called for.
The client is implemented atop a new AMQP protocol engine that is
implemented as a more reactive or event based model than the existing
proton-j engine which can hide some important details due to the
temporal squashing that occurs in its state machine, that means some
state changes can’t be discerned. This new engine exists within a new
set of Maven coordinates and Java packages which allows us to preserve
and support the existing Java-based engine for the foreseeable future.
The new engine is similarly subject to change.
I dont expect this has been tried with e.g IoT Hub yet as a fairly new
still in progress piece of work. However I also wouldn't expect to
need specific client examples if it were, since the client is really
server agnostic and has no server-specific behaviours of its own.
The examples simply use "localhost" as the hostname since that is
simple, and a fairly typical place for examples to connect to a server
of choice. You are free to point it elsewhere, the client itself
doesnt really know the server is local, it just connects to the
provided hostname and any hostname can be given.
The main thing I expect you might have noticed in this case is the
apparent lack of an authenticated example. I'd agree that would be
worth adding something there, even if only doc, to make things clearer
around that. It is pretty simple: there are connect(..) methods that
also take a ConnectionOptions arg in addition to the shown host+port,
and the ConnectionOptions can be used to provide credentials (in
addition to other things).
I wanted to provide a short update on this client work.
* The client now has working reconnect support with configuration
options for max reconnect attempts, max delay between attempts etc
having been made available.
* New examples have been created to demonstrate the basics of enabling
* Testing of the large message send and receive has been done with
payload sizes of up to 2GB and multiple fixes have been made to make
this work reliably.
* Some additional convenience APIs have been added throughout the client
API to make using it simpler to use for the general use cases.
* Many new tests have been added both in the underlying engine and the
client with fixes to address issues found along the way.
* The client has been tested against ActiveMQ Artemis, ActiveMQ 5.x and
the Dispatch Router.
Just as a reminder the client code is located in the following Github