Basic: Missing a fundamental concept with applications, appreciate help - `mix run` not waiting

Can you post mix.exs for this app?

Pretty standard, really:

defmodule MyApp.Mixfile do
  use Mix.Project

  def project do
    [
      app: :myapp,
      version: "0.0.1",
      elixir: "~> 1.4",
      start_permanent: Mix.env == :prod,
      deps: deps()
    ]
  end

  def application do
    [
      mod: {Example.App, []},
      extra_applications: [:logger]
    ]
  end

  defp deps do
    [
      {:verk, "~> 1.0"},
      {:distillery, "~> 1.5", runtime: false}
    ]
  end
end

mix run without --no-halt:

[info] Schedule Manager started
[info] Queue Manager started for queue default
[info] Workers Manager started for queue default (running)
[info] Added 0 jobs.
[info] No more jobs to be added to the queue default from inprogress list.
[info] Queue Manager started for queue priority
[info] Workers Manager started for queue priority (running)
[info] Added 0 jobs.
[info] No more jobs to be added to the queue priority from inprogress list.

..then exits immediately. As if I am running it as a script.

As I say, I think I am missing some fundamental concept behind how applications work.

See this for a starting point. If my understanding is correct mix essentially starts the processes in it’s own OS process and after it finishes the starting script it exits - taking the BEAM with it. In a development environment you are meant to use iex -s mix to run the application (vs. running a script).

Thanks. I did find that before, and was a little confused with:

def start(_type, _args) do
  IO.puts "starting"
  Task.start(fn -> :timer.sleep(1000); IO.puts("done sleeping") end)
end

In this case we are starting a simple process in our callback that just sleeps for one second and then outputs something - this is enough to satisfy the API of the start callback but we don’t see “done sleeping”. The reason for this is that by default mix run will exit once that callback has finished executing. In order for that not to happen you need to use mix run --no-halt - in this case the VM will not be stopped.

From what I am gathering, I will be responsible for writing something which halts exit? It is the fact it is exiting by default that is throwing me off.

If I am planning to build long-running apps, what is the suggestion? Can I use mix run --no-halt in development and distillery to create a release for production?

In a production deploy the application is started in it’s own process. mix run simply runs the application startup just like any other code but then exits because it is done running the code. The process of launching the application in production is entirely different. You do not use mix in production.

I won’t be using mix in production. I’ll be using distilleryto create a release and running through bin/myapp foreground etc.

But in the case of development, how do you run long-running processes for your app? I’m currently using mix run --no-halt which is working fine for my purposes, but am now interested how others are handling this.

As I stated before - typically you would be using iex -S mix so you could observe and interact with the running application directly.

Supervisor and Application: Starting Applications (You may want to start at Introduction to Mix)

Apologies! Got carried away on the SO post.

Thanks for the clarifications. I’ll go through the getting started guides before posting more questions.

I don’t think it’s helped that I’ve taken on Phoenix at the same time.

Using --no-halt is standard (unless you want the shell with iex -S mix). Even Phoenix’s phx.server adds --no-halt internally: phoenix/lib/mix/tasks/phx.server.ex at v1.3.0-rc.2 · phoenixframework/phoenix · GitHub

So don’t worry about it, that’s the correct usage. In production you would use e.g. distillery as you have said.

I’m not sure that is the core issue - it probably has more to do with the “I want to do Rails/Sidekiq in Elixir/Phoenix” approach. Lots of people approach Elixir/Phoenix with a “I learn best by doing a interesting project” attitude, not allowing for the fact that their current mindset may not be ideal for working with Elixir/Phoenix. This is a theme in Cameron Price’s Micropatterns: Learning to Reach Quickly for the Right Tool - where he found out that for him personally it was necessary to do lots of little exercises before his mindset shifted sufficiently before it made sense to attempt a larger project.

Now I know nothing about either Sidekiq or Verk but from scanning Verk’s documentation I’m getting the impression that the intention is to insert Verk into your application’s supervision tree - much like Ecto is running in the supervision tree of the application that is running Phoenix - so you are also confronted headfirst with OTP.

This is where another common point of confusion comes into play:

mix new hello_world

creates a library application, while

mix new hello_world --sup

creates what you more conventionally would think of as an “application”. A library application doesn’t implement the application callbacks and as a result can’t be started or stopped. Most library applications will however still autonomously manage their own processes once they are included in the primary application’s supervision tree.

So it seems to me that Verk’s primary intent is to be run in the same primary application that is already running Ecto and the various bits that Phoenix relies on like Cowboy.

I’m used to having app and worker processes separated and scaling them separately. As such, I might have one app server on one box and 3 workers on other boxes.

Now this describes a somewhat different situation. Usually a “box” is running a node and it’s the node that is running your primary application. So each “box” runs it’s own node with applications running in it. Your description sounds like you intend to run Verk on a node that is separate from Phoenix (possibly even Ecto as part of yet another application on yet another node). This can be accomplished with distributed Elixir but interestingly:

Sorry if I came across as discouraging the use of --no-halt. To me it just seemed more advantageous to seize the opportunity to shed a bit more light of what an “application” actually is in the Elixir world rather than sweeping it under the carpet with --no-halt.