-
Notifications
You must be signed in to change notification settings - Fork 123
2.0 Release Notes
Version 2.0 includes some internal improvements (see SelectiveConsumer support section for the details) and it should make the library performant and stable. All users are recommended to use this new version.
Version 2.0 includes one breaking change. Don’t worry - the change won’t affect the majority of users and you can check it easily.
We made this change to keep aligning with RabbitMQ. We don’t think many users use this option so you unlikely get affected. Try searching your project with no_wait
just in case. If the result is not shown, you don’t have to do anything for the change.
In case your application uses the option for the AMQP API calls or message handling, rename the option to nowait
.
All APIs will still accept the no_wait
key on 2.x to keep the backward compatibility as much as possible.
However the callback (e.g. basic_cancel) uses nowait
key from version 2.x.
In case you use a pattern matching against the callback parameter with no_wait
you have to change it to nowait
.
# this will still work but we recommend you to change to `nowait: true`
{:ok, _} = AMQP.Basic.consume(chan, queue, self(), no_wait: true)
# this won't work. you have to change the matching key to `nowait`
{:ok, _} = AMQP.Basic.cancel(chan, consumer_tag)
receive do
{:basic_cancel_ok, %{consumer_tag: tag, no_wait: false}} -> IO.puts("hi")
end
Like you can see this issue, the progress report by Erlang library is pretty verbose and confuses some users. We are in favour of silencing by default so it will be disabled at the application starts. If you want to enable the report add the following line to your config file.
config :amqp, enable_progress_report: true
Or you can toggle it with AMQP.Application
module.
Introduce Elixir implementation of SelectiveConsumer and eliminate the receiver process This change is probably a highlight of version 2.0 and expected to improve the reliability of this library. When receiving a message from RabbitMQ, the library had a broker process that converts an Erlang record to a Map data which is a more familiar data type for Elixir developers.
(message) > [Erlang channel] > [Erlang SelectiveConsumer] > [AMQP broker] > [User consumer]
From v2, we do the conversion on our implementation of SelectiveConsumer.
(message) > [Erlang channel] > [AMQP SelectiveConsumer] > [User consumer]
AMQP SelectiveConsumer is supervised by the Erlang channel process and provides the exact same behavior as Erlang SelectiveConsumer (plus data conversion). This structure change will eliminate process communication per message and the chance of encountering an edge case that AMQP broker is going down.
AMQP now provides a way to set up a connection and channel in config. The configured connection and channel are opened at the start of the application and reconnected automatically when they are down. You can access them through the AMQP.Application module.
config :amqp, connection: [], channel: []
Access:
{:ok, chan} = AMQP.Application.get_channel()
Check out the documentation for AMQP.Application.get_connection/1
and AMQP.Application.get_channel/1
for more details.
- Accept Integer type for the expiration option
- Accept DateTime type for the timestamp option
That’s all! If you have any questions please don’t hesitate to open an issue and ask us away.