Elixir Supervise multiple RabbitMQ Consumer workers - rabbitmq

I have been following along the RabbitMQ Work Queues tutorial for Elixir (Elixir Work Queues) which works quite nicely. On top of that I am now trying to get multiple consumers started and monitored by a Supervisor.
This last portion is proving to be a bit tricky. If I run the below code in 2 separate iex sessions, both are getting & handling messages from RabbitMQ.
Client (consumer)
defmodule MT.Client do
require Logger
#host Application.get_env(:mt, :host)
#username Application.get_env(:mt, :username)
#password Application.get_env(:mt, :password)
#channel Application.get_env(:mt, :channel)
def start_link do
MT.Client.connect
end
def connect do
{:ok, connection} = AMQP.Connection.open(host: #host, username: #username, password: #password)
{:ok, channel} = AMQP.Channel.open(connection)
AMQP.Queue.declare(channel, #channel, durable: true)
AMQP.Basic.qos(channel, prefetch_count: 1)
AMQP.Basic.consume(channel, #channel)
Logger.info "[*] Waiting for messages"
MT.Client.loop(channel)
end
def loop(channel) do
receive do
{:basic_deliver, payload, meta} ->
Logger.info "[x] Received #{payload}"
payload
|> to_char_list
|> Enum.count(fn x -> x == ?. end)
|> Kernel.*(1000)
|> :timer.sleep
Logger.info "[x] Done."
AMQP.Basic.ack(channel, meta.delivery_tag)
MT.Client.loop(channel)
end
end
end
Supervisor
defmodule MT.Client.Supervisor do
use Supervisor
require Logger
#name MTClientSupervisor
def start_link do
Supervisor.start_link(__MODULE__, :ok, name: #name)
end
def init(:ok) do
children = [
worker(MT.Client, [], restart: :transient, id: "MTClient01"),
worker(MT.Client, [], restart: :transient, id: "MTClient02"),
worker(MT.Client, [], restart: :transient, id: "MTClient03")
]
supervise(children, strategy: :one_for_one)
end
end
When running that in an iex session:
iex -S mix
MT.Client.Supervisor.start_link
Following is logged:
08:46:50.746 [info] [*] Waiting for messages
08:46:50.746 [info] [x] Received {"job":"TestMessage","data":{"message":"message........"}}
08:46:58.747 [info] [x] Done.
08:46:58.748 [info] [x] Received {"job":"TestMessage","data":{"message":"last........"}}
08:47:06.749 [info] [x] Done.
So clearly there in only 1 consumer active, which is consuming the messages sequentially.
Running the below in 2 iex sessions:
MT.Client.start_link
I'm not adding the logs here, but in this case I get 2 consumes handling messages at the same time
I am sure that I am simply not grasping the required details for Agent/GenServer/Supervisor. Anyone can point out what needs to be changed to MT.Client & MT.Client.Supervisor above to achieve the idea of having multiple consumers active on the same channel?
Also; I'm been experimenting with spawning a Consumer agent and using the resulting pid in AMQP.Basic.consume(channel, #channel, pid) - but that's failing as well.

Related

how to retry connect ampq in Elixir

I'm trying to connect to a RabbitMQ instance using the ampq package on Elixir, but at times the RabbitMQ instance won't be available at the time that the Elixir server is running. I was wondering how I might be able to implement a simple retry mechanism. There's one strategy here but that seems more involved than I feel necessary especially since there's a mention of it on the README about more information being found on the official docs. I unfortunately couldn't find anything.
Edit: This will crash the application on start and exit.
My code for the module is as follows:
Server.Gen.Rabbit (child)
defmodule Server.Gen.Rabbit do
use GenServer
use AMQP
defmodule State do
#type t :: %{
id: String.t(),
chan: map()
}
defstruct id: "", chan: nil
end
def start_link(%{id: id}) do
GenServer.start_link(
__MODULE__,
%State{
id: id
},
name: :"#{id}:rabbit"
)
end
def init(opts) do
host = "amqp://guest:guest#localhost"
case Connection.open(host) do
{:ok, conn} ->
{:ok, chan} = Channel.open(conn)
setup_queue(opts.id, chan)
:ok = Basic.qos(chan, prefetch_count: 1)
queue_to_consume = #online_receive_queue <> opts.id
IO.puts("queue_to_consume_online: " <> queue_to_consume)
{:ok, _consumer_tag} = Basic.consume(chan, queue_to_consume, nil, no_ack: true)
{:ok, %State{chan: chan, id: opts.id}}
{:error, _} ->
IO.puts("[Rabbit] error on connecting to server: #{host}")
{:backoff, 5_000}
end
end
Server (parent)
defmodule Server do
use Application
def start(_type, _args) do
import Supervisor.Spec, warn: false
children = [
{
GenRegistry,
worker_module: Server.Gen.Rabbit
},
Plug.Cowboy.child_spec(
scheme: :http,
plug: Server.Router,
options: [
port: String.to_integer(System.get_env("PORT") || "3000"),
dispatch: dispatch(),
protocol_options: [idle_timeout: :infinity]
]
)
]
opts = [strategy: :one_for_one, name: Server.Supervisor]
Supervisor.start_link(children, opts)
end
end

elixir test fails with "Reason: already started"

I'm currently working on my first big elixir project and wanted to properly utilize testing this time.
However, if I add my Modules to the "normal" supervisor, i cannot start them again with start_supervised! and all tests fail with Reason: already started: #PID<0.144.0>
Here is my code:
(application.ex)
defmodule Websocks.Application do
# See https://hexdocs.pm/elixir/Application.html
# for more information on OTP Applications
#moduledoc false
use Application
def start(_type, _args) do
children = [
{Websocks.PoolSupervisor, []},
{Websocks.PoolHandler, %{}}
# {Websocks.Worker, arg}
]
# See https://hexdocs.pm/elixir/Supervisor.html
# for other strategies and supported options
opts = [strategy: :one_for_one, name: Websocks.Supervisor]
Supervisor.start_link(children, opts)
end
end
Some of my tests:
defmodule PoolHandlerTest do
use ExUnit.Case, async: true
alias Websocks.PoolHandler
doctest PoolHandler
setup do
start_supervised!({PoolHandler, %{}})
%{}
end
test "adding two pools and checking if they are there" do
assert PoolHandler.add(:first) == :ok
assert PoolHandler.add(:second) == :ok
assert PoolHandler.get_pools() == {:ok,%{:first => nil, :second => nil}}
end
and the pool handler:
defmodule Websocks.PoolHandler do
use GenServer
# Client
def start_link(default) when is_map(default) do
GenServer.start_link(__MODULE__, default, name: __MODULE__)
end
# Server (callbacks)
#impl true
def init(arg) do
{:ok, arg}
end
end
(I cut out the stuff i think is not necessary, but the complete code is on github here: github)
Thanks in advance for any help i get!
As #Everett mentioned in the comment - your application will already be started for you when you mix test, so there is no need to start your GenServers again. It seems like you're interacting with the global instance in your test, so if that's what you want, then it should just work.
However, if you'd like to start a separate instance just for your test, you need to start an unnamed one. For example, you could add an optional pid argument to your wrapper functions:
defmodule Websocks.PoolHandler do
# ...
def add(server \\ __MODULE__, value) do
GenServer.call(server, {:add, value})
end
# ...
end
Then, instead of using using start_supervised! like you do, you can start an unnamed instance in your setup and use it in your tests like so:
setup do
{:ok, pid} = GenServer.start_link(PoolHandler, %{})
{:ok, %{handler: pid}}
end
test "adding two pools and checking if they are there", %{handler: handler} do
PoolHandler.add(handler, :first)
# ...
end

Fix “owner #PID<…> exited with: shutdown” in tests for my terminate/2 method of Phoenix.Channel

Looking for a help with testing terminate/2 callback in my Channel.
Test and setup looks like this:
setup do
:ok = Ecto.Adapters.SQL.Sandbox.checkout(MyApp.Repo)
Ecto.Adapters.SQL.Sandbox.mode(MyApp.Repo, {:shared, self()})
{:ok, socket} = connect(UserSocket, %{token: "some_token"})
{:ok, %{}, socket} = subscribe_and_join(socket, "some_channel", %{})
%{socket: socket}
end
test "terminate/2", %{socket: socket} do
# for avoiding "** (EXIT from #PID<...>) {:shutdown, :closed}"
Process.unlink(socket.channel_pid)
assert close(socket) == :ok
# some additional asserts go here
end
In terminate/2 method I just call a helper module, let's name it TerminationHandler.
def terminate(_reason, _socket) do
TerminationHandler.call()
end
And call/0 method in TerminationHandler contains a DB query. It can look like this i.e
def call() do
users = User |> where([u], u.type == "super") |> Repo.all # line where error appears
# some extra logic goes here
end
This is the error that I get periodically (maybe once in 10 runs)
14:31:29.312 [error] GenServer #PID<0.1041.0> terminating
** (stop) exited in: GenServer.call(#PID<0.1040.0>, {:checkout, #Reference<0.3713952378.42205187.247763>, true, 60000}, 5000)
** (EXIT) shutdown: "owner #PID<0.1039.0> exited with: shutdown"
(db_connection) lib/db_connection/ownership/proxy.ex:32: DBConnection.Ownership.Proxy.checkout/2
(db_connection) lib/db_connection.ex:928: DBConnection.checkout/2
(db_connection) lib/db_connection.ex:750: DBConnection.run/3
(db_connection) lib/db_connection.ex:644: DBConnection.execute/4
(ecto) lib/ecto/adapters/postgres/connection.ex:98: Ecto.Adapters.Postgres.Connection.execute/4
(ecto) lib/ecto/adapters/sql.ex:256: Ecto.Adapters.SQL.sql_call/6
(ecto) lib/ecto/adapters/sql.ex:436: Ecto.Adapters.SQL.execute_or_reset/7
(ecto) lib/ecto/repo/queryable.ex:133: Ecto.Repo.Queryable.execute/5
(ecto) lib/ecto/repo/queryable.ex:37: Ecto.Repo.Queryable.all/4
(my_app) lib/my_app/helpers/termination_handler.ex:4: MyApp.Helpers.TerminationHandler.call/0
(stdlib) gen_server.erl:673: :gen_server.try_terminate/3
(stdlib) gen_server.erl:858: :gen_server.terminate/10
(stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
Last message: {:join, Phoenix.Channel.Server}Last message: {:join, Phoenix.Channel.Server}
Would appreciate any responses regarding reasons of this error and possible ways to avoid it.
As stated in the documentation for GenServer.terminate/2:
[...] the supervisor will send the exit signal :shutdown and the GenServer will have the duration of the timeout to terminate. If after duration of this timeout the process is still alive, it will be killed immediately.
That is seemingly your case. DBConnection.checkout/2 seems to be waiting for the available connection to appear and this is lasted beyond the timeout. Hence the owner experiences a brutal kill.
There could be two possible solutions:
increase a timeout of shutdown (I would avoid that)
increase an amount of allowed simultaneous database connections.
The latter is likely needed in any case, since your pool seems to be full. That way the connection would be checked out immediately, and it should return in the timeout interval successfully.
This might help.
defmacro leave_channel(socket) do
quote do
Process.unlink(unquote(socket).channel_pid)
mref = Process.monitor(unquote(socket).channel_pid)
ref = leave(unquote(socket))
assert_reply ref, :ok
assert_receive {:DOWN, ^mref, :process, _pid, _reason}
end
end
defmacro close_socket(socket) do
quote do
Process.unlink(unquote(socket).channel_pid)
mref = Process.monitor(unquote(socket).channel_pid)
close(unquote(socket))
assert_receive {:DOWN, ^mref, :process, _pid, _reason}
end
end

WebSocket error occurred: wrong number of arguments (given 2, expected 1)

I try to create connection to cable server and subscribe on channel, but I get error with log:
Started GET "/cable" for 172.20.0.1 at 2017-05-27 08:29:39 +0000
Started GET "/cable/" [WebSocket] for 172.20.0.1 at 2017-05-27 08:29:39 +0000
Successfully upgraded to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: upgrade, HTTP_UPGRADE: websocket)
WebSocket error occurred: wrong number of arguments (given 2, expected 1)
My code:
// order_slots.coffee
jQuery(document).ready ->
//some jquery code that call create_channel function
create_channel = (order_id) ->
App.cable.subscriptions.create {
channel: "OrderSlotsChannel",
order_id: order_id
},
connected: ->
# Called when the subscription is ready for use on the server
disconnected: ->
# Called when the subscription has been terminated by the server
received: (data) ->
# Data received
Specific channel:
//order_slots_channel
class OrderSlotsChannel < ApplicationCable::Channel
def subscribed
stream_from "order_slots_#{params[:order_id]}_channel"
end
def unsubscribed; end
end
And ActionCable connection:
# Be sure to restart your server when you modify this file. Action Cable runs in a loop that does not support auto reloading.
module ApplicationCable
class Connection < ActionCable::Connection::Base
identified_by :current_user
def connect
self.current_user = find_verified_user
logger.add_tags 'ActionCable', current_user.email
end
protected
def find_verified_user
verified_user = env['warden'].user
verified_user || reject_unauthorized_connection
end
end
end
ActionCable::Channel::Base - is just empty. I will appreciate any help. Thanks in advance
I solved this problem. The project used Passenger Phusion as application server and 5.0.x version badly combine with rails 5.1 and action cable. You should update passenger up to 5.1.x

How to start bunny thread in Rails and Thin

I'm integrating Bunny gem for RabbitMQ with Rails, should I start Bunny thread in an initializer that Rails starts with application start or do it in a separate rake task so I can start it in a separate process ?
I think if I'm producing messages only then I need to do it in Rails initializer so it can be used allover the app, but if I'm consuming I should do it in a separate rake task, is this correct ?
You are correct: you should not be consuming from the Rails application itself. The Rails application should be a producer, in which case, an initializer is the correct place to start the Bunny instance.
I essentially have this code in my Rails applications which publish messages to RabbitMQ:
# config/initializers/bunny.rb
MESSAGING_SERVICE = MessagingService.new(ENV.fetch("AMQP_URL"))
MESSAGING_SERVICE.start
# app/controllers/application_controller.rb
class ApplicationController
def messaging_service
MESSAGING_SERVICE
end
end
# app/controllers/uploads_controller.rb
class UploadsController < ApplicationController
def create
# save the model
messaging_service.publish_resize_image_request(model.id)
redirect_to uploads_path
end
end
# lib/messaging_service.rb
class MessagingService
def initialize(amqp_url)
#bunny = Bunny.new(amqp_url)
#bunny.start
at_exit { #bunny.stop }
end
attr_reader :bunny
def publish_resize_image_request(image_id)
resize_image_exchange.publish(image_id.to_s)
end
def resize_image_exchange
#resize_image_exchange ||=
channel.exchange("resize-image", passive: true)
end
def channel
#channel ||= bunny.channel
end
end
For consuming messages, I prefer to start executables without Rake involved. Rake will fork a new process, which will use more memory.
# bin/image-resizer-worker
require "bunny"
bunny = Bunny.new(ENV.fetch("AMQP_URL"))
bunny.start
at_exit { bunny.stop }
channel = bunny.channel
# Tell RabbitMQ to send this worker at most 2 messages at a time
# Else, RabbitMQ will send us as many messages as we can absorb,
# which would be 100% of the queue. If we have multiple worker
# instances, we want to load-balance between each of them.
channel.prefetch(2)
exchange = channel.exchange("resize-image", type: :direct, durable: true)
queue = channel.queue("resize-image", durable: true)
queue.bind(exchange)
queue.subscribe(manual_ack: true, block: true) do |delivery_info, properties, payload|
begin
upload = Upload.find(Integer(payload))
# somehow, resize the image and/or post-process the image
# Tell RabbitMQ we processed the message, in order to not see it again
channel.acknowledge(delivery_info.delivery_tag, false)
rescue ActiveRecord::RecordNotFound => _
STDERR.puts "Model does not exist: #{payload.inspect}"
# If the model is not in the database, we don't want to see this message again
channel.acknowledge(delivery_info.delivery_tag, false)
rescue Errno:ENOSPC => e
STDERR.puts "Ran out of disk space resizing #{payload.inspect}"
# Do NOT ack the message, in order to see it again at a later date
# This worker, or another one on another host, may have free space to
# process the image.
rescue RuntimeError => e
STDERR.puts "Failed to resize #{payload}: #{e.class} - #{e.message}"
# The fallback should probably be to ack the message.
channel.acknowledge(delivery_info.delivery_tag, false)
end
end
Given all that though, you may be better off with pre-built gems and using Rails' abstraction, ActiveJob.