yggdrasil_rabbitmq v4.1.1 Yggdrasil.RabbitMQ.Application View Source
This project is a RabbitMQ adapter for Yggdrasil
publisher/subscriber.
Small example
The following example uses RabbitMQ adapter to distribute messages:
iex(1)> channel = %Yggdrasil.Channel{
iex(1)> name: {"amq.topic", "some_channel"},
iex(1)> adapter: :rabbitmq
iex(1)> }
iex(2)> Yggdrasil.subscribe(channel)
iex(3)> flush()
{:Y_CONNECTED, %Yggdrasil.Channel{(...)}}
and to publish a message for the subscribers:
iex(4)> Yggdrasil.publish(channel, "message")
iex(5)> flush()
{:Y_EVENT, %Yggdrasil.Channel{(...)}, "message"}
When the subscriber wants to stop receiving messages, then it can unsubscribe from the channel:
iex(6)> Yggdrasil.unsubscribe(channel)
iex(7)> flush()
{:Y_DISCONNECTED, %Yggdrasil.Channel{(...)}}
RabbitMQ adapter
The RabbitMQ adapter has the following rules:
- The
adapter
name is identified by the atom:rabbitmq
. - The channel
name
must be a tuple with the exchange and the routing key. - The
transformer
must encode to a string. From thetransformer
s provided it defaults to:default
, but:json
can also be used. - Any
backend
can be used (by default is:default
).
The following is an example of a valid channel for both publishers and subscribers:
%Yggdrasil.Channel{
name: {"amq.topic", "postgres_channel_name"},
adapter: :rabbitmq,
transformer: :json
}
It will expect valid JSONs from RabbitMQ and it will write valid JSONs in RabbitMQ.
RabbitMQ configuration
Uses the list of options for AMQP
, but the more relevant optuons are
shown below:
hostname
- RabbitMQ hostname (defaults to"localhost"
).port
- RabbitMQ port (defaults to5672
).username
- RabbitMQ username (defaults to"guest"
).password
- RabbitMQ password (defaults to"guest"
).virtual_host
- Virtual host (defaults to"/"
).subscriber_options
- Controls the amount of connections established with RabbitMQ. These arepoolboy
options for RabbitMQ subscriber (defaults to[size: 5, max_overflow: 10]
).
The following shows a configuration with and without namespace:
# Without namespace
config :yggdrasil,
rabbitmq: [hostname: "rabbitmq.zero"]
# With namespace
config :yggdrasil, RabbitMQOne,
postgres: [
hostname: "rabbitmq.one",
port: 1234
]
Also the options can be provided as OS environment variables. The available variables are:
YGGDRASIL_RABBITMQ_HOSTNAME
or<NAMESPACE>_YGGDRASIL_RABBITMQ_HOSTNAME
.YGGDRASIL_RABBITMQ_PORT
or<NAMESPACE>_YGGDRASIL_RABBITMQ_PORT
.YGGDRASIL_RABBITMQ_USERNAME
or<NAMESPACE>_YGGDRASIL_RABBITMQ_USERNAME
.YGGDRASIL_RABBITMQ_PASSWORD
or<NAMESPACE>_YGGDRASIL_RABBITMQ_PASSWORD
.YGGDRASIL_RABBITMQ_VIRTUAL_HOST
or<NAMESPACE>_YGGDRASIL_RABBITMQ_VIRTUAL_HOST
.
where <NAMESPACE>
is the snakecase of the namespace chosen e.g. for the
namespace RabbitmqTwo
, you would use RABBITMQ_TWO
as namespace in the OS
environment variable.
Installation
Using this RabbitMQ adapter with Yggdrasil
is a matter of adding the
available hex package to your mix.exs
file e.g:
def deps do
[{:yggdrasil_rabbitmq, "~> 4.1"}]
end
Link to this section Summary
Functions
Called when an application is started
Link to this section Functions
Called when an application is started.
This function is called when an application is started using
Application.start/2
(and functions on top of that, such as
Application.ensure_started/2
). This function should start the top-level
process of the application (which should be the top supervisor of the
application’s supervision tree if the application follows the OTP design
principles around supervision).
start_type
defines how the application is started:
:normal
- used if the startup is a normal startup or if the application is distributed and is started on the current node because of a failover from another node and the application specification key:start_phases
is:undefined
.{:takeover, node}
- used if the application is distributed and is started on the current node because of a failover on the nodenode
.{:failover, node}
- used if the application is distributed and is started on the current node because of a failover on nodenode
, and the application specification key:start_phases
is not:undefined
.
start_args
are the arguments passed to the application in the :mod
specification key (e.g., mod: {MyApp, [:my_args]}
).
This function should either return {:ok, pid}
or {:ok, pid, state}
if
startup is successful. pid
should be the PID of the top supervisor. state
can be an arbitrary term, and if omitted will default to []
; if the
application is later stopped, state
is passed to the stop/1
callback (see
the documentation for the c:stop/1
callback for more information).
use Application
provides no default implementation for the start/2
callback.
Callback implementation for Application.start/2
.