yggdrasil_rabbitmq v4.1.1 Yggdrasil.RabbitMQ.Application View Source

Build Status Hex pm hex.pm downloads

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 the transformers 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 to 5672).
  • 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 are poolboy 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 node node.
  • {:failover, node} - used if the application is distributed and is started on the current node because of a failover on node node, 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.