Elixian

Macro 101

gozalex — Mon, 8 Aug 2022 13:46:51 +0900

Basic

terms
- Expression : 표현식, 코드
- Represent : 코드를 표현하는 방식, AST consist of Three element tuples
- Quote : 인용, 특정 코드 덩어리의 Representation을 가져오는 것
- Unquote : 인용하는 것이 아니라 Evaluation 된 코드 결과

Elixir는 이미 데이터 구조와 함수를 사용하여 간단하고 읽기 쉬운 방식으로 일상적인 코드를 작성할 수 있는 메커니즘을 제공합니다. 매크로는 최후의 수단으로만 사용해야 합니다. 명시적(explicit)이 암시적(implicit)보다 낫다는 것을 기억하십시오. Concise Code보다 Clear Code가 좋습니다.
·메타 프로그래밍의 첫번째 단계는 표현식이 어떻게 나타나는지를 이해하는 것입니다. Elixir 코드는내부적으로 추상 문법 트리(Abstract Syntax Tree, AST)로 표현하는데, 이는 함수 이름과 메타데이터, 함수의 인자를 포함하는 튜플로 이루어져 있습니다.
AST tuple은 다음 형식에 따라 구성됩니다.

{atom | tuple, list, list | atom}

첫 번째 요소는 동일한 representation의 atom 또는 tuple입니다.
두 번째 요소는 숫자 및 컨텍스트와 같은 메타데이터를 포함하는 keyword list입니다.
세 번째 요소는 함수 호출 또는 atom에 대한 argument list 입니다. 이 요소가 atom이면tuple이 variable을 represent 하는 것입니다.

위에 정의된 tuple 외에도 5개의 Elixir Literal Representation이 있습니다. 이 Literal은 인용(Quote)될 때 Tuple이 아닌 스스로를 반환합니다.

:sum #=> atom
1.0 #=> float, integer
[1, 2] #=> list
"string" #=> 문자열
{key, value} #=> 두 개의 element가 있는 tuple

function과 macro의 차이

defmodule Unless do

  def fun_unless(clause, do: expression) do
    if(!clause, do: expression)
  end
 
  defmacro macro_unless(clause, do: expression) do
    quote do
      if(!unquote(clause), do: unquote(expression))
    end
  end
end

iex(1)> Unless.fun_unless false, do: IO.puts "this should never be printed"
this should never be printed
:ok
iex(2)> Unless.fun_unless true, do: IO.puts "this should never be printed"
this should never be printed
nil

Fun.unless/2를 호출 하였을 때 첫 번째 파라미터가 true던 false던 상관없이 모두 “this should never be printed”가 출력 됩니다.
그러나 리턴 값은 :ok와 nil 로 서로 다릅니다.
다른 예를 한 번 보겠습니다.

iex(3)> Unless.fun_unless false, do: 1+3
4
iex(4)> Unless.fun_unless true, do: 1+3
nil

첫 번째 파라미터가 false 일 경우, 4가 리턴 되었습니다. 그러나 true일 경우, nil 이 리턴 됩니다.
위의 예와 차이점이 명확하게 보입니다. do: 절에 있는 코드의 Evaluate여부 입니다.
함수는 인수를 받아 Evaluate하여 함수 내부로 전달합니다. 그러나 매크로는 인용된 표현식(quoted expression)을 수신하고 이를 인용부(quote do 절)에 삽입하고 마지막으로 다른 인용된 표현식(quoted expression)을 반환합니다.
IO.puts 문장은 함수 구현에서 인쇄되었지만 매크로 구현에서는 인쇄되지 않았습니다. 이는 함수 호출에 대한 인수가 함수를 호출하기 전에 Evaluate되기 때문입니다. 그러나 매크로는 인수를 평가하지 않습니다. 대신 인용된 표현으로 인수를 받은 다음 다른 인용된 표현으로 변환됩니다.

iex(5)> Unless.macro_unless false, do: IO.puts "this should never be printed"
this should never be printed
:ok
iex(6)> Unless.macro_unless true, do: IO.puts "this should never be printed"
nil

Macro의 정의에 의해 위의 macro_unless 에 IO.puts 는 Evaluate 되지 않고 macro 안의quote 절에 삽입되어 새로운 quoted expression으로 리턴 됩니다.
Quote는 특정 코드 덩어리의 Representation을 가져오는 것입니다. 그러나 때로는 가져오려는 Representation 내부에 다른 특정 코드 덩어리를 주입해야 할 수도 있습니다.
예를 들어, 인용된 표현식 안에 삽입하려는 숫자가 포함된 변수 숫자가 있다고 가정합니다.

iex> number = 13
iex> Macro.to_string(do: 11 + number)

"11 + number"

number 변수의 값이 삽입되지 않았고 expression에서 number가 인용되었기 때문에 우리가 원하는 것이 아닙니다. Number에 값을 삽입하려면 quote do 절 안에 unquote를 사용해야 합니다.

iex> number = 13
iex> Macro.to_string(quote do: 11 + unquote(number))

"11 + 13"

디버깅

아래는 매크로로 생성된 코드를 확인하고 싶을 때, 사용할 수 있습니다.
매크로로 생성된 코드를 확인하고 싶다면, 코드를 Macro.expand/2, Macro.expand_once/2로합칠 수 있습니다. 다음은 __ENV__를 사용하여 IEx와 소스를 합칩니다.
Expand 함수는 주어진 감싸진 코드로 매크로를 확장합니다. 첫 번째는 여러 번 확장됩니다. 하지만 뒤에 것은 한번만 확장됩니다. 예를 들어, 이 전 단락의 unless 예제를 수정해 봅시다.

defmodule OurMacro do

  defmacro unless(expr, do: block) do
    quote do
      if !unquote(expr), do: unquote(block)
    end
  end
end
 
require OurMacro
 
quoted =
  quote do
    OurMacro.unless(true, do: "Hi")
  end

quoted |> Macro.expand_once(__ENV__) |> Macro.to_string |> IO.puts

if(!true) do
  "Hi"
end

같은 코드를 Macro.expand/2로 실행하면, 흥미로운 결과가 나옵니다.

quoted |> Macro.expand(__ENV__) |> Macro.to_string |> IO.puts

case(!true) do
  x when x in [false, nil] ->
    nil
  _ ->
    "Hi"
end

Elixir에서 if는 매크로입니다. 여기에서 기저의 case 구문으로 확장되는 것을 확인할 수 있습니다.
즉, 소스를 합치는 것을 “확장한다”라고 표현하는 이유는 어디에 Expand 하는지에 따라 다른quoted expression이 생성될 수 있기 때문입니다.

Macro Hygiene

기본적으로 Elixir 매크로는 청결하며 컨텍스트와 충돌하지 않습니다.

defmodule Example do

  defmacro hygienic do
    quote do: val = -1
  end
end
 
iex> require Example
nil
iex> val = 42
42
iex> Example.hygienic
-1
iex> val
42

val을 조작하고 싶은 경우에는 Hygiene하지 않은 변수를 원한다는 것을 알리기 위해서 var!/2를사용하면 됩니다.

defmodule Example do

  defmacro hygienic do
    quote do: val = -1
  end
 
  defmacro unhygienic do
    quote do: var!(val) = -1
  end
end
 
require Example
nil
iex> val = 42
42
iex> Example.hygienic
-1
iex> val
42
iex> Example.unhygienic
-1
iex> val
-1

매크로에서 var!/2를 사용하는 것으로 매크로에게 val 값을 넘기지 않고, 이를 조작하였습니다. 청결하지 않은 매크로를 사용하는 것은 최소화해야 합니다. var!/2를 사용하는 것은 변수 해결시에충돌이 발생할 위험성을 증가시키게 됩니다.
이미 unquote/1라는 편리한 매크로를 배웠습니다만, 이외에도 코드에 값을 주입하는바인딩이라는 방법이 있습니다.

defmodule Example do

  defmacro double_puts(expr) do
    quote do
      IO.puts(unquote(expr))
      IO.puts(unquote(expr))
    end
  end
end
 
Example.double_puts(:os.system_time)
1450475941851668000
1450475941851733000

시간이 다릅니다! 무슨 일이 있었던 걸까요? unquote/1를 같은 표현식에 여러 번 사용하는 것은재평가를 발생시키며 예상치 못한 결과를 가져옵니다. bind_quoted를 사용해서 예제를 변경해봅시다.
변수 바인딩을 통해 매크로의 내부에 여러 변수를 포함하고, 한번만 quote 되도록 보장하는 것으로예상치 못한 재평가를 회피할 수 있습니다.
바인딩된 변수를 사용하려면 quote/2의 bind_quoted 옵션에 키워드 리스트를 넘겨주면 됩니다.

defmodule Example do

  defmacro double_puts(expr) do
    quote bind_quoted: [expr: expr] do
      IO.puts(expr)
      IO.puts(expr)
    end
  end
end
 
iex> require Example
nil
iex> Example.double_puts(:os.system_time)
1450476083466500000
1450476083466500000

Debugging using Livebook

gozalex — Thu, 21 Jul 2022 18:15:57 +0900

Elixir Korea Meetup 에서 Livebook 을 사용한 관련 Topic을 세미나 한다길래 꼭 들으려 했으나

피치 못할 사정으로 노쇼하는 바람에 따로 시간 내어 조사해 봤습니다.

#노쇼노매너 #노쇼 #엘릭서밋업

예전에 설치했던 Livebook을 업그레이드 하고, erlang dbg모듈을 사용해 봤습니다.

아래는 테스트 화면입니다.

#훌륭 #OTP #Process #RemoteProcess #Cluster

와.. 이건 뭐 사기캐인가?

Debug Using Livebook

Install as an Escript

This is the easiest way to use Livebook locally.

This assumes you are doing Elixir development locally and are setup for Elixir development.

Following the Livebook Escript README section,

this is how you install Livebook.

$ mix escript.install hex livebook

Then locally launching Livebook is:

$ livebook server

Upgrading When Using an Escript

When upgrading your Livebook version while using asdf for managing your Elixir and Erlang installs,

then here's a helpful tip:

Remove the existing livebook shim: rm ~/.asdf/shims/livebook
Install the new version: mix escript.install hex livebook
Re-shim to get the command: asdf reshim elixir
Verify you have the upgrade: livebook --version

참고자료

https://fly.io/docs/getting-started/elixir/

The Fly Global Application Platform · Fly Docs

Documentation and guides from the team at Fly.io.

fly.io

https://fly.io/docs/app-guides/elixir-static-cookie/

The Fly Global Application Platform · Fly Docs

Documentation and guides from the team at Fly.io.

fly.io

https://fly.io/docs/elixir/advanced-guides/connect-livebook-to-your-app/

Connecting Livebook to Your App in Production

Documentation and guides from the team at Fly.io.

fly.io

https://kaiwern.com/posts/2020/11/02/debugging-with-tracing-in-elixir/

Debugging With Tracing in Elixir | kw7oe

If you are a video person, and have 24 minutes to spend with, just jump over to this ElixirConf 2020 - Debugging Live Systems on the BEAM talk by Jeffery Utter. This article is a downgraded version of the video . I wrote this before the video is publis

kaiwern.com

https://www.erlang.org/doc/man/dbg.html#tracer-0

Erlang -- dbg

When tracing function calls on a group leader process (an IO process), there is risk of causing a deadlock. This will happen if a group leader process generates a trace message and the tracer process, by calling the trace handler function, sends an IO requ

www.erlang.org

들어가기 전에...

 iex --sname fit --cookie iQ-VfumnytJJ9omnF8s...oNzwDsRIQlrsTA== -S mix phx.server

위와 같이 Trace 할 프로젝트를 실행합니다.

시작:dbg

추적을 시작하기 전에 다음 코드로 dbg 및 tracer 프로세스를 시작해야 합니다.

tracer는 단순히 생각해서 receive block 안에서 log를 출력해주는 일을 하는 간단한 모듈이라고 생각하면 됩니다.

:dbg.start
:dbg.tracer

명시적으로 추적하려는 것을 명시할 때까지 아무 작업도 수행하지 않습니다.

추적할 대상 지정

시스템에서 호출된 Enum.map/2 함수를 추적한다고 가정해 보겠습니다. 다음을 실행하여 지정할 수 있습니다.

:dbg.tp(Enum, :map, 2, [])
:dbg.p(:all, :c)

코드의 일부가 Enum.map([1,2,3], & &1 + 1)을 호출하면 위의 :dbg 코드를 실행하는 위치에 따라 쉘에서 다른 출력을 얻게 됩니다.

Local Shell (응용 프로그램 코드 실행)

Local Shell에서 시스템을 실행하는 셸에 있는 경우 추적한 함수가 호출될 때마다 다음과 같은 내용이 표시됩니다.

(<0.106.0>) call 'Elixir.Enum':map([1,2,3],#Fun<erl_eval.44.97283095>)

Remote Shell (여기서 셸 프로세스가 애플리케이션을 실행하는 프로세스에 연결되었다고 가정)

Remote Shell 에서는 Tracer가 Remote Shell 대신 라이브 프로세스에서 출력을 기록하기 때문에 출력이 표시되지 않습니다. 추적을 보려면 로그 파일(예: erlang.log.1)을 살펴봐야 합니다.

Remote Shell에서 출력하려면 추적 프로그램 프로세스를 다르게 시작해야 합니다.

:dbg.tracer(:process, {fn msg, n -> IO.inspect(msg); n+1 end, 0})

:dbg.tracer는 추적된 각 이벤트를 처리하는 방법을 사용자 정의할 수 있는 두 번째 인수를 허용합니다.

여기서 우리는 대신 Local Shell에 출력을 기록하도록 Tracer에게 지시합니다.

추적 중지

추적을 중지하려면 다음과 같이 간단합니다.

:dbg.stop_clear

필요한 정보를 얻은 후 추적을 중지하는 것이 매우 중요합니다.

그 이유는 다음과 같습니다.

추적은 시스템에 대한 추가 오버헤드입니다.
IO/로그에 기록합니다. 따라서 디스크 공간을 차지합니다.

이것은 특히 High Frequency 또는 High Volume 시스템을 추적할 때 중요합니다.

따라서 실제 프로덕션 시스템에서 추적 프로그램을 시작할 때 다음을 사용하는 것이 실제로 더 좋습니다.

:dbg.tracer(:process, {fn _, 5 -> :dbg.stop_clear()
                        msg, n -> IO.inspect(msg); n+1 end, 0})

첫 번째 함수 절은 추적자에게 5개의 이벤트가 발생한 후 중지하도록 지시합니다.

두 번째 절은 추적자에게 수신 이벤트를 처리하는 방법을 알려줍니다. 이 경우에는 인쇄만 하고 카운터를 증가시킵니다.

All Together

:dbg.start
:dbg.tracer(:process, {fn _, 5 -> :dbg.stop_clear()
                        msg, n -> IO.inspect(msg); n+1 end, 0})
:dbg.tpl(Enum, :map, [])
:dbg.p(:all, :c)

# With trace
Enum.map([1,2,3,4], & &1 + 1)
Enum.map([1,2,3,4], & &1 + 1)
Enum.map([1,2,3,4], & &1 + 1)
Enum.map([1,2,3,4], & &1 + 1)
Enum.map([1,2,3,4], & &1 + 1)

# No more trace
Enum.map([1,2,3,4], & &1 + 1)

때로는 함수에 전달되는 인수보다 더 많은 것을 알고 싶을 수도 있고,

Return Value 또는 함수가 실행될 때의 타임스탬프를 알고 싶을 수도 있습니다.
위에서 사용한 일부 함수에 더 많은 인수를 제공하여 이를 달성할 수 있습니다.

Return Value 를 Trace하고 싶다면 다음과 같이 :dbg.tpl에 더 많은 옵션을 지정할 수 있습니다.

:dbg.start
:dbg.tracer

:dbg.tpl(Enum, :map, 2, [{:_, [], [{:return_trace}]}])

:dbg.p(:all, :c)

Enum.map([1,2,3], & &1 + 1)
# (<0.106.0>) call 'Elixir.Enum':map([1,2,3],#Fun<erl_eval.44.97283095>)
# (<0.106.0>) returned from 'Elixir.Enum':map/2 -> [2,3,4]
# [2,3,4]

:dbg.stop

* 추가 옵션 MatchSpec 은 Document 에서 참고하세요

함수 호출의 타임스탬프를 포함하려면 :dbg.p를 호출할 때 :timestamp를 포함할 수 있습니다.

:dbg.start
:dbg.tracer
:dbg.tpl(Enum, :map, 2, [{:_, [], [{:return_trace}]}])

:dbg.p(:all, [:c, :timestamp])

Enum.map([1,2,3,4], & &1 + 1)
# [2, 3, 4, 5]
# (<0.105.0>) call 'Elixir.Enum':map([1,2,3,4],#Fun<erl_eval.44.40011524>) (Timestamp: {1624, 687361, 187278})
# (<0.105.0>) returned from 'Elixir.Enum':map/2 -> [2,3,4,5] (Timestamp: {1624, 687361, 187303})
# ^ The timestmap is in Erlang Timestamp tuple format.

:dbg.stop

보다 구체적인 함수 호출 추적

특정 인수(예: 사용자 ID 또는 특정 범주)로 호출된 함수만 추적할 수도 있습니다.

:dbg.tpl에 대한 MatchSpec을 수정하여 이를 수행할 수 있습니다.

:dbg.tpl(Enum, :map, 2, [{[[1, 2, 3], :_], [], [{:return_trace}]}])

MatchSpec의 첫 번째 튜플에 있는 첫 번째 인수는 일치시키려는 함수 매개변수입니다.

여기에서 Enum.map/2를 다음과 일치시키려고 합니다.

첫 번째 매개변수 일치 [1,2,3]
두 번째 매개변수 일치 :_는 무엇이든 됩니다.

:return_trace를 둘러싸는 {}에 유의하세요. Tracer가 Return Value 도 추적할 수 있도록 하는 것이 중요합니다.

:dbg.start
:dbg.tracer

:dbg.tpl(Enum, :map, 2, [{[[1, 2, 3], :_], [], [{:return_trace}]}])

:dbg.p(:all, :c)

Enum.map([1,2,3], & &1 + 1)
# (<0.106.0>) call 'Elixir.Enum':map([1,2,3],#Fun<erl_eval.44.97283095>)
# (<0.106.0>) returned from 'Elixir.Enum':map/2 -> [2,3,4]
# [2, 3, 4]

Enum.map([1,2], & &1 + 1)
# Nothing is logged
# [2, 3]

복잡한 시나리오에서는 매치 스펙을 작성하기 어려울 수 있습니다.

운 좋게도 :dbg.fun2ms를 사용하여 함수를 일치 사양으로 변환할 수 있습니다.

:dbg.fun2ms(fn [[1,2,3], _] -> :return_trace end)
# [{[1, 2, 3], [], [:return_trace]}]

그러나 MatchSpec이 완전히 정확하지는 않습니다.

Return Value 추적이 올바르게 작동하려면 {}로 래핑해야 합니다. 그래서 이것은 작동하지 않을 것입니다:

:dbg.start
:dbg.tracer

match_spec = :dbg.fun2ms(fn [[1,2,3], _] -> :return_trace end)
:dbg.tpl(Enum, :map, match_spec)
:dbg.p(:all, :c)

# With trace of function call but no return value
Enum.map([1,2,3], & &1 + 1)
# (<0.105.0>) call 'Elixir.Enum':map([1,2,3],#Fun<erl_eval.44.40011524>)
# [2, 3, 4]

:dbg.stop

따라서 일치 사양을 약간 변형해야 합니다. 방법은 다음과 같습니다.

:dbg.start
:dbg.tracer

match_spec = :dbg.fun2ms(fn [[1,2,3], _] -> :return_trace end)
match_spec = Enum.map(match_spec, fn {args, guards, [:return_trace]} ->
  {args, guards, [{:return_trace}]}
end)

:dbg.tpl(Enum, :map, match_spec)
:dbg.p(:all, :c)

# With trace of function call and return value.
Enum.map([1,2,3], & &1 + 1)
# (<0.105.0>) call 'Elixir.Enum':map([1,2,3],#Fun<erl_eval.44.40011524>)
# (<0.105.0>) returned from 'Elixir.Enum':map/2 -> [2,3,4]
# [2, 3, 4]

Summary

:dbg는 Low Level의 디버깅 툴 입니다. 더 간단한 인터페이스를 선호한다면 recon에서 recon_trace를 사용하는 것을 고려하십시오.
recon_trace에 비해 :dbg의 이점 중 하나는 내장되어 있다는 것입니다. 코드베이스에 추가 종속성을 추가할 필요가 없습니다. 그러나 특히 라이브 프로덕션 시스템에서 이 작업을 많이 수행하는 경우에는 recon을 종속 항목으로 추가하고 대신 recon_trace를 사용하는 것이 좋습니다.

Recon은 단순한 trace보다 훨씬 더 많은 도구를 제공합니다. 또한 시스템을 안전하게 진단할 수 있습니다. 이와 같은 주제에 관심이 있다면 Recon의 저자가 recon 등으로 BEAM 응용 프로그램을 진단하는 것에 대해 쓴 Erlang in Anger의 무료 사본을 얻을 수도 있습니다.

정찰과 함께 추적을 사용하는 방법에 대해 자세히 알아보려면 여기에서도 읽을 수 있습니다.

본 내용은 Livebook 내용에 Kai 블로그를 번역하여 추가하였습니다.

원문은 https://kaiwern.com/posts/2020/11/02/debugging-with-tracing-in-elixir/ 를 참고하세요

GenServer를 어떻게 종료할 것인가?

gozalex — Wed, 25 Aug 2021 18:26:43 +0900

https://alexcastano.com/how-to-stop-a-genserver-in-elixir/

원문입니다.

Why and how a GenServer stops?

The different possibilities to stop a GenServer and how to handle the termination process.

alexcastano.com

terminate/2 콜백

GenServer가 중지되는 이유를 살펴보기 전에 terminate/2 콜백을 살펴보겠습니다. 필수 사항은 아니며 필요할 때만 구현할 수 있지만 중단하기 전에 무언가를 하고 싶다면 도움이 될 수 있습니다. terminate/2 콜백이 실행된 이후에는 GenServer의 상태를 영원히 잃게 되므로 state를 변경할 마지막 기회입니다.

이 함수는 두 개의 인수를 수신합니다. 첫 번째 인수는 종료 이유이고 두 번째 인수는 프로세스의 마지막 상태입니다.

How a GenServer can stop itself

defmodule Buggy do
  use GenServer

  @impl true
  def init(state) do
    {:ok, state}
  end

  @impl true
  def handle_info({:div, num}, state) do
    state = state + 1
    IO.inspect(":div received, updating state to: #{state}")
    IO.inspect("Divission = 100 / #{num} = #{100 / num}")
    {:noreply, state}
  end

  @impl true
  def terminate(reason, state) do
    IO.inspect("terminate/2 callback")
    IO.inspect({:reason, reason})
    IO.inspect({:state, state})
  end
end

GenServer 프로세스 자체에서 중지하는 방법과 다른 프로세스에서 GenServer를 중지하는 두 가지 방법이 있습니다. 첫 번째 것부터 시작하겠습니다.

iex> {:ok, pid} = GenServer.start(Buggy, 0)
{:ok, #PID<0.139.0>}

iex> send(pid, {:div, 10})
{:div, 10}
":div received, updating state to: 1"
"Divission = 100 / 10 = 10.0"

iex> send(pid, {:div, 0})
{:div, 0}
":div received, updating state to: 2"
"terminate/2 callback"
{:reason,
 {:badarith,
  [
    {Buggy, :handle_info, 2, [file: 'buggy.ex', line: 13]},
    {:gen_server, :try_dispatch, 4, [file: 'gen_server.erl', line: 680]},
    {:gen_server, :handle_msg, 6, [file: 'gen_server.erl', line: 756]},
    {:proc_lib, :init_p_do_apply, 3, [file: 'proc_lib.erl', line: 226]}
  ]}}
{:state, 1}
## Error log
"""
18:00:28.809 [error] GenServer #PID<0.139.0> terminating
** (ArithmeticError) bad argument in arithmetic expression
    buggy.ex:13: Buggy.handle_info/2
    (stdlib 3.13) gen_server.erl:680: :gen_server.try_dispatch/4
    (stdlib 3.13) gen_server.erl:756: :gen_server.handle_msg/6
    (stdlib 3.13) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
Last message: {:div, 0}
State: 1
"""

terminate /2 콜백에 의해 수신된 상태가 마지막 handle_call/2 콜백이 호출되기 전의 마지막 상태라는 것을 확인하는 것은 흥미롭습니다. 업데이트된 상태를 반환할 기회가 없었으므로 이것이 GenServer 동작이 할 수 있는 최선입니다. 이 패턴을 더 많이 볼 것이므로 terminate /2 콜백을 개발할 때 염두에 두십시오.

iex> {:ok, pid} = GenServer.start(Raising, 0)
{:ok, #PID<0.150.0>}

iex> send(pid, :raising)
":raising received, updating state to: 1"
:raising
"terminate/2 callback"
{:reason,
 { %RuntimeError{message: "Raising!"},
  [
    {Raising, :handle_info, 2, [file: 'raising.ex', line: 13]},
    {:gen_server, :try_dispatch, 4, [file: 'gen_server.erl', line: 680]},
    {:gen_server, :handle_msg, 6, [file: 'gen_server.erl', line: 756]},
    {:proc_lib, :init_p_do_apply, 3, [file: 'proc_lib.erl', line: 226]}
  ]}}
{:state, 0}
## Error log
"""
18:08:25.685 [error] GenServer #PID<0.150.0> terminating
** (RuntimeError) Raising!
    raising.ex:13: Raising.handle_info/2
    (stdlib 3.13) gen_server.erl:680: :gen_server.try_dispatch/4
    (stdlib 3.13) gen_server.erl:756: :gen_server.handle_msg/6
    (stdlib 3.13) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
Last message: :raising
State: 0
"""

Raise Exception은 위와 비슷합니다. Log를 남기며 프로세스가 죽습니다.

Return :stop in a callback

defmodule Stop do
  use GenServer

  @impl true
  def init(state) do
    {:ok, state}
  end

  @impl true
  def handle_info({:quit, reason}, state) do
    state = state + 1
    IO.inspect(":quit received, updating state to: #{state}")
    {:stop, reason, state}
  end
  
  @impl true
  def handle_info({:exit, reason}, _state) do
    IO.inspect(":exit received")
    exit(reason)
  end

  @impl true
  def terminate(reason, state) do
    IO.inspect("terminate/2 callback")
    IO.inspect({:reason, reason})
    IO.inspect({:state, state})
  end
end

Exception이 발생하던 아니면 인위적으로 Exception을 발생 시키던 상관 없습니다. 그러나 대부분의 경우 GenServer를 중지하는 가장 적절한 방법은 거의 모든 콜백에서 {:stop, reason, state} 튜플을 반환하는 것입니다.

iex> {:ok, pid} = GenServer.start(Stop, 0)
{:ok, #PID<0.160.0>}

iex> send(pid, {:quit, :normal})
{:quit, :normal}
":quit received, updating state to: 1"
"terminate/2 callback"
{:reason, :normal}
{:state, 1}

State도 업데이트가 되고 Log도 남기지 않습니다.

Kernel.exit/1

{:stop, reason, state} 튜플을 반환하는 것과 매우 유사한 동작을 합니다. 이 함수는 현재 프로세스(이 경우에는 GenServer)에 종료 신호를 보냅니다.

iex> {:ok, pid} = GenServer.start(Exit, 0)
{:ok, #PID<0.192.0>}
iex> send(pid, {:exit, :normal})
{:exit, :normal}
":exit received"
"terminate/2 callback"
{:reason, :normal}
{:state, 0}

{:stop, reason, state} 튜플을 반환하는 것과 마찬가지로 Log를 남기지 않고 죽습니다. 다만 handle_info/2 에서 exit/1로 빠져나와 별도의 State를 관리하는 리턴 값이 없으므로 State를 변경할 수는 없습니다.

Important note about the “reason”

{:stop, reason, state} 튜플을 반환하는 것과 exit(reason)을 통해 우리는 GenServer를 중지하는 "reason"를 조작할 수 있습니다. 이 이유는 OTP에 대한 다른 중요한 의미가 있습니다.

"정상적인" reason 값으로 간주되는 세 가지 값이 있습니다.

:normal
:shutdown
{:shutdown, term}

만약 reason이 위의 세 값과 다르면 어떻게 될까요? GenServer Document에 따르면

“정상적인 reason값이 아닌” 다른 이유로 종료하면 비정상으로 간주되어 충돌로 처리됩니다. 이는 OTP 기본 Supervisor 동작이 시작되고 오류 보고서가 내보내지는 등의 작업을 의미합니다.”

이렇게 말이죠

iex> {:ok, pid} = GenServer.start(Exit, 0)
{:ok, #PID<0.204.0>}
iex> send(pid, {:exit, :my_own_reason})
{:exit, :my_own_reason}
":exit received"
"terminate/2 callback"
{:reason, :my_own_reason}
{:state, 0}
## Error log
"""
18:34:29.527 [error] GenServer #PID<0.204.0> terminating
** (stop) :my_own_reason
    exit.ex:12: Exit.handle_info/2
    (stdlib 3.13) gen_server.erl:680: :gen_server.try_dispatch/4
    (stdlib 3.13) gen_server.erl:756: :gen_server.handle_msg/6
    (stdlib 3.13) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
Last message: {:exit, :my_own_reason}
State: 0
"""

{:stop, :my_own_reason, state}도 마찬가지입니다.

How a GenServer can be stopped externally

우리는 이미 GenServer가 스스로를 멈출 수 있는 방법을 보았습니다. 이제 다른 프로세스가 동일한 작업을 수행할 수 있는 방법을 살펴보겠습니다.

GenServer.stop/3

이 함수는 PID(또는 GenServer 이름으로 간주될 수 있는 모든 값)를 수신하여 중지 reason와 timeout을 수신합니다. timeout 매개변수로 인해 상상할 수 있듯이 이 기능은 동기식이며 GenServer가 완전히 중지될 때까지 계속되지 않습니다.

defmodule GenServerStop do
use GenServer

  @impl true
  def init(state) do
    {:ok, state}
end

  @impl true
  def terminate(reason, state) do
    IO.inspect("terminate/2 callback")
    IO.inspect({:reason, reason})
    IO.inspect({:state, state})
    IO.inspect("sleep before terminating")
    Process.sleep(1_000)
    IO.inspect("really terminating")
  end
end

iex> {:ok, pid} = GenServer.start(GenServerStop, 0)
{:ok, #PID<0.127.0>}
iex> GenServer.stop(pid)
"terminate/2 callback"
{:reason, :normal}
{:state, 0}
"sleep before terminating"
"really terminating"
:ok

reason에 대한 기본값은 :normal이고 timeout에 대한 기본값은 5_000입니다. 다시 말하지만, 종료 Reason이 사용자 정의라면 다음과 같이 기록됩니다.

iex> {:ok, pid} = GenServer.start(GenServerStop, 0)
{:ok, #PID<0.131.0>}
iex> GenServer.stop(pid, :abnormal)
"terminate/2 callback"
{:reason, :abnormal}
{:state, 0}
"sleep before terminating"
"really terminating"
# Error log
"""
09:35:49.180 [error] GenServer #PID<0.131.0> terminating
** (stop) :abnormal
Last message: []
State: 0
"""
:ok

종료할 시간이 충분하지 않으면 GenServer.stop/3 함수가 반환되지 않고 반환되기 전에 충돌이 발생합니다. 그러나 terminate/2는 완료됩니다. 다음을 확인하세요

iex> {:ok, pid} = GenServer.start(GenServerStop, 0)
{:ok, #PID<0.135.0>}
iex> GenServer.stop(pid, :small_timeout, 100)
"terminate/2 callback"
{:reason, :small_timeout}
{:state, 0}
"sleep before terminating"
# Our current iex process exit because timeout, Error log:
"""
** (exit) exited in: GenServer.stop(#PID<0.135.0>, :small_timeout, 100)
    ** (EXIT) time out
    (elixir 1.10.3) lib/gen_server.ex:981: GenServer.stop/3
"""
# The GenServer process finishes anyway some milliseconds later
"really terminating"
# Error log because is not a normal reason:
"""
09:38:39.020 [error] GenServer #PID<0.135.0> terminating
** (stop) :small_timeout
Last message: []
State: 0
"""

Link to another process

defmodule Link do
  use GenServer

  @impl true
  def init(state) do
    IO.inspect({:init, self()})
    {:ok, state}
  end

  @impl true
  def handle_info({:link, link}, state) do
    Process.link(link)
    {:noreply, state}
  end

  @impl true
  def terminate(reason, state) do
    IO.inspect("terminate/2 callback in pid #{inspect(self())}")
    IO.inspect({:reason, reason})
    IO.inspect({:state, state})
  end
end

iex> {:ok, pid_1} = GenServer.start(Link, 0)
{:init, #PID<0.120.0>}
{:ok, #PID<0.120.0>}
iex> {:ok, pid_2} = GenServer.start(Link, 0)
{:init, #PID<0.122.0>}
{:ok, #PID<0.122.0>}
iex> send(pid_1, {:link, pid_2})
{:link, #PID<0.122.0>}
iex> GenServer.stop(pid_2, :my_own_reason)
terminate/2 callback in pid #PID<0.122.0>
{:reason, :my_own_reason}
{:state, 0}
# Error log from pid 2:
"""
18:57:10.499 [error] GenServer #PID<0.122.0> terminating
** (stop) :my_own_reason
Last message: []
State: 0
"""
:ok
iex> Process.alive?(pid_1)
false

우리는 pid_2를 중지했고 그것이 terminate/2 콜백을 실행하는 것을 확인할 수 있습니다. pid_1의 경우에도 마찬가지입니다. pid_1로 실행 중인 GenServer가 pid_2에 연결되어 종료되었습니다. 흥미롭게도 pid_1에 대해 terminate/2 콜백이 전혀 호출되지 않았습니다.

반면 GenServer.stop(pid_2, :normal) 을 사용하면 pid_2는 종료되지만 pid_1은 살아있습니다. 이 경우는 pid_2의Supervisor Strategy에 따라 다르게 동작합니다.

:permanent - the child process is always restarted.

:temporary - the child process is never restarted, regardless of the supervision strategy: any termination (even abnormal) is considered successful.

:transient - the child process is restarted only if it terminates abnormally, i.e., with an exit reason other than :normal, :shutdown, or {:shutdown, term}.

Trapping Exit Signal

이 기본 동작을 수정할 수 있는 한 가지 방법은 Exit Signal을 Trapping하는 것입니다. 프로세스가 죽으면 연결된 프로세스는 종료 신호를 받습니다. 두 가지 가능성이 있습니다.

프로세스는 종료 신호를 트랩하지 않으므로 동일한 이유로 종료됩니다.
프로세스는 종료 신호를 트랩하므로 일반 메시지로 변환됩니다.

defmodule TrapLink do
use GenServer

  @impl true
  def init(state) do
    # Trap exits
    Process.flag(:trap_exit, true)
    {:ok, state}
  end

  @impl true
  def handle_info({:link, link}, state) do
    Process.link(link)
    {:noreply, state}
  end

  def handle_info(msg, state) do
    IO.inspect({:handle_info, self(), msg, state})
    {:noreply, state}
  end

  @impl true
  def terminate(reason, state) do
    IO.inspect("terminate/2 callback in pid #{inspect(self())}")
    IO.inspect({:reason, reason})
    IO.inspect({:state, state})
  end
end

마지막 경우의 예는 다음과 같습니다.

iex> {:ok, pid_1} = GenServer.start(TrapLink, 0)
{:ok, #PID<0.187.0>}
iex> {:ok, pid_2} = GenServer.start(TrapLink, 0)
{:ok, #PID<0.189.0>}
iex> send(pid_1, {:link, pid_2})
{:link, #PID<0.189.0>}
iex> GenServer.stop(pid_2, :normal)
"terminate/2 callback in pid #PID<0.189.0>"
{:reason, :normal}
{:state, 0}
# This message is received by the pid_1
{:handle_info, {:EXIT, #PID<0.189.0>, :normal}, 0}
:ok
iex> Process.alive?(pid_1)
true

이번에는 pid_1에서 실행 중인 GenServer가 살아남았습니다. 죽지 않았기 때문에 terminate/2 콜백도 호출되지 않았습니다. 대신 handle_info/2 콜백에서 {:EXIT, #PID<0.189.0>, :normal} 메시지를 받았습니다. "정상적인" 이유가 아닌 경우에도 동일한 동작이 발생합니다. 위는 정상적인 종료, 아래는 비정상 종료의 예입니다.

iex> {:ok, pid_1} = GenServer.start(TrapLink, 0)
{:ok, #PID<0.198.0>}
iex> {:ok, pid_2} = GenServer.start(TrapLink, 0)
{:ok, #PID<0.200.0>}
iex> send(pid_1, {:link, pid_2})
{:link, #PID<0.200.0>}
iex> GenServer.stop(pid_2, :abnormal)
"terminate/2 callback in pid #PID<0.200.0>"
{:reason, :abnormal}
{:state, 0}
# Error log from pid_2:
"""
19:28:14.982 [error] GenServer #PID<0.200.0> terminating
** (stop) :abnormal
Last message: []
State: 0
"""
# This message is received by the pid_1
{:handle_info, {:EXIT, #PID<0.200.0>, :abnormal}, 0}
:ok

물론, handle_info/2 콜백에서 우리는 이전에 본 다른 방법 중 하나를 사용하여 GenServer를 중지하기로 결정할 수 있었습니다. 그러나 요점은 연결된 프로세스가 죽을 때 종료 신호를 트랩하면 GenServer가 Trap한 프로세스는 죽지 않는다는 것입니다. 이 작업은 수동으로 수행해야 합니다.

Process.exit/2

우리는 Exit Signal에 대해 배웠습니다. 모든 프로세스는 다른 프로세스에 종료 신호를 보낼 수 있습니다. 이를 위해Process.exit/2 함수를 사용할 수 있습니다. 이전 예에서와 같이 이 함수를 호출한 결과는 신호가 트랩되었는지 여부에 따라 달라집니다.

GenServer.stop(pid, :normal)은 해당 pid를 죽이지만 Process.exit(pid, :normal)은 해당 pid를 죽이지 않습니다. 헷갈리지 마세요~

defmodule ExternalExit do
use GenServer

  @impl true
  def init(state) do
    {:ok, state}
end

  @impl true
  def handle_info(:trap, state) do
    Process.flag(:trap_exit, true)
    {:noreply, state}
end

  def handle_info(msg, state) do
    IO.inspect({:info, msg, state})
    {:noreply, state}
end

  @impl true
  def terminate(reason, state) do
    IO.inspect("terminate/2 callback")
    IO.inspect({:reason, reason})
    IO.inspect({:state, state})
  end
end

iex> {:ok, pid} = GenServer.start(ExternalExit, 0)
{:ok, #PID<0.156.0>}
iex> Process.exit(pid, :abnormal)
true
iex> Process.alive?(pid)
false
iex> {:ok, pid} = GenServer.start(ExternalExit, 0)
{:ok, #PID<0.160.0>}
iex> Process.exit(pid, :shutdown)
true
iex> Process.alive?(pid)
false

그리고 다시 말하지만 외부에서 Process.exit/2를 이용해 GenServer를 죽이는 경우, GenServer는 Exit Signal로 terminate/2 콜백을 실행하지 않습니다. 신호를 받자마자 죽습니다. 위의 다른 경우와는 다르게 :shutdown reason으로 프로세스를 죽이면 normal과 유사하게 동작하지 않습니다. 오히려 비정상 reason 처럼 동작합니다. 즉, :normal reason만이 “정상적인 이유”로 프로세스를 종료할 수 있습니다.

normal의 의미는 Internal Exit 이면 정상적 종료로 해석되고External Exit면 종료되지 않습니다. 외부에서 “정상 종료”라는 것을 할 수 없다고 보기 때문입니다.
shutdown의 경우 Internal Exit면 의도한 정상 종료로 해석되고 External Exit이면 외부에서 누군가가 shutdown한 것이므로 비정상으로 해석합니다.

반면 신호가 트랩되면 수동으로 원하지 않는 한 죽지 않습니다.

iex> {:ok, pid} = GenServer.start(ExternalExit, 0)
{:ok, #PID<0.164.0>}
iex> send(pid, :trap)
:trap
iex> Process.exit(pid, :abnormal)
{:info, {:EXIT, #PID<0.111.0>, :abnormal}, 0}
true
iex> Process.alive?(pid)
true

Process.exit/2 기능을 사용할 때 이전 동작에 대한 두 가지 예외가 있습니다. 첫째, normal reason를 사용할 때입니다. 이 경우 문서에는 다음과 같이 나와 있습니다.

“이유가 atom :normal이면 pid가 종료되지 않습니다(pid가 호출 프로세스인 경우가 아니면:normal로 종료됨). 종료를 트래핑하는 경우 종료 신호는 {:EXIT, from, :normal} 메시지로 변환되어 해당 메시지 대기열로 전달 된다.”

iex> {:ok, pid} = GenServer.start(ExternalExit, 0)
{:ok, #PID<0.169.0>}
iex> Process.exit(pid, :normal)
true
iex> Process.alive?(pid)
true
iex> send(pid, :trap)
:trap
iex> Process.exit(pid, :normal)
{:info, {:EXIT, #PID<0.111.0>, :normal}, 0}
true
iex> Process.alive?(pid)
true

종료 신호를 트래핑하지 않은 경우에도 프로세스가 죽지 않았음을 알 수 있습니다!

다른 예외는 :kill 이유와 함께 사용할 때입니다.

이유가 atom :kill인 경우, 즉 Process.exit(pid, :kill)이 호출되면 트래핑할 수 없는 종료 신호가 pid로 전송되어 무조건reason :killed와 함께 종료됩니다.

iex> {:ok, pid} = GenServer.start(ExternalExit, 0)
{:ok, #PID<0.185.0>}
iex> send(pid, :trap)
:trap
iex> Process.exit(pid, :kill)
true
iex> Process.alive?(pid)
false

결론

GenServer를 종료하는 100가지 다른 방법이 있을 수 있습니다. 우리는 그것들 모두를 살펴보지는 않았지만 가장 일반적인 것들을 공부했습니다. 상황에 가장 적합한 것을 사용하십시오.

마지막 권장 사항으로, terminate/2 콜백이 항상 실행되는 것은 아니므로 맹목적으로 신뢰하지 마십시오. GenServer가 죽을 때 코드를 실행해야 하는 경우 종료 신호를 캡처하는 다른 연결된 프로세스를 만드는 것이 가장 좋습니다. 코드는 "링크 프로세스" 예제와 매우 유사합니다.

추가)

terminate/2 콜백

1. GenServer 외부에서 Process.exit(:abnormal) 로 죽였을 경우, terminate/2 콜백이 호출되지 않는다.

2. Link Process가 abnormal 로 종료되면 Linked Process 는 terminate/2 콜백이 호출되지 않는다.

Elixir Process

gozalex — Mon, 28 Jun 2021 19:57:51 +0900

exit(pid, reason)

Sends an exit signal with the given reason to pid.

The following behaviour applies if reason is any term except :normal or :kill:

If pid is not trapping exits, pid will exit with the given reason.
If pid is trapping exits, the exit signal is transformed into a message {:EXIT, from, reason} and delivered to the message queue of pid.

If reason is the atom :normal, pid will not exit (unless pid is the calling process, in which case it will exit with the reason :normal). If it is trapping exits, the exit signal is transformed into a message{:EXIT, from, :normal} and delivered to its message queue.

If reason is the atom :kill, that is if Process.exit(pid, :kill) is called, an untrappable exit signal is sent to pid which will unconditionally exit with reason :killed.

Inlined by the compiler.

Examples

Process.exit(pid, :kill) #=> true

Understanding Exit Signals in Erlang/Elixir

Written by Emil Soman on February 29, 2016;

“Process linking and how processes send and handle exit signals” - a very important topic to understand in order to build robust apps in Erlang or Elixir, but also the source of a lot of confusions for beginners. In this post, we’ll cover this topic and understand it well, once and for all.

Note: Processes are the same in both Erlang and Elixir, so everything below is equally applicable to both languages.

Processes

Processes in Erlang are like threads that don’t share any data. These processes are VM level, so don’t confuse them with OS processes. These VM level processes are scheduled for execution by the Erlang VM, like how the OS schedules the OS level processes for execution. Since these Erlang processes own their own data, they are scheduled freely on all available CPUs and this is how Erlang makes concurrency easy for developers.

But a bunch of processes that run in isolation are rarely of any use. To build anything useful, processes need to work together by communicating with each other.

Messages

In Erlang processes communicate among themselves by message passing. Every process has one mailbox. A process can read messages that appear in its mailbox and can also send messages to mailboxes that belong to other processes. This way, processes can communicate with each other without having to share any data. This frees developers from writing locks around data access when writing code that may run concurrently.

Apart from these regular messages, processes also communicate using “exit signals”, a special type of message.

Exit Signals

Processes have a signalling mechanism by which they can let other processes know that they are exiting. These “exit signals” also contain an exit reason, which help other processes to decide how to react to the signal.

A process can terminate for 3 reasons:

A normal exit - This happens when a process is done with its job and ends execution. Since these exits are normal, usually nothing needs to be done when they happen. So these signals are usually ignored, but they are emitted anyway for the sake of interested processes. The exit reason for this kind of exit is the atom :normal.
Because of unhandled errors - This happens when an exception is raised inside the process and not caught. A pattern matching error is an example - a technique used by Erlang programmers to “fail fast”. The exit reason for this kind of exit is the exception details - name of the exception and some stack trace.
Forcefully killed - This happens when another process sends an exit signal with the reason :kill, which forces the receiving process to terminate.

A process can subscribe to another process’s exit signal by establishing a “link” with that process. When a process terminates, all the linked processes receive the exit signal from the terminating process.

The force-kill signals, the ones with exit reason :kill, will terminate the receiving process no matter what. But the other kinds of exit signals - those with reasons :normal or any other reason - can cause different effects on the receiving process depending on whether the receiving process is trapping exits or not. Let’s see how trapping of exit signals works.

Trapping exits

When a process traps exit signals, the exit signals that are received from the links will be converted into messages which are then put inside the mailbox that belongs to the process. Here’s how a process can trap exits in Elixir:

Process.flag(:trap_exit, true) receive do {:EXIT, from, reason} -> # Handle exit as needed

When this process receives an exit signal other than :kill signal, it will be converted into a message that will be received inside the receive block. In Erlang/Elixir, this is what makes supervisor trees possible.

A supervisor is a process whose responsibility is to start child processes and keep them alive by restarting them if necessary. Let’s see how a supervisor does that. If you look at the source codeof supervisor in Erlang, you can see that the first thing that happens in the init function is trapping exit signals:

init(...) -> process_flag(trap_exit, true), ...

This means that exit signals from child processes will be converted into messages. The supervisor then handles these messages by restarting the child processes, based on the restart strategy of the supervisor. This is how you write fault tolerant apps in Elixir or Erlang - you let your processes fail fast, and the supervisor that spawned these processes will make sure they are restarted.

So if processes can trap exit signals, how is it possible to kill them? Using the :kill exit signal, of course. The exit reason :kill is used to forcefully terminate the receiving process even if it’s trapping exits.

In Elixir, this is how you kill a process using its pid:

Process.exit(pid, :kill)

A process can also send an exit signal to itself using:

Process.exit(self(), <reason>)

The process responds to this signal from self in a similar manner it would respond to an exit signal it receives from another process, but with one exception. If a process sends itself an exit signal with the reason :normal, the process terminates and when it does, it sends a :normal exit signal to all linked processes.

Recap

:normal exit signals are harmless. These are ignored by the receiving process unless trapping exits, in which case, these will be received as messages. If it’s sent by self, it will cause the process to terminate with a :normal exit reason.
:kill exit signals always result in the termination of the receiving process.
Exit signals with other reasons will terminate the receiving process unless trapping exits, in which case, these will be received as messages.

Process Register

gozalex — Mon, 5 Apr 2021 00:04:04 +0900

defmodule Segway.Context.Registry do
  use GenServer

  # API
  @doc """
    ## start_link

    ## Examples
      iex> {:ok, pid} = GenServer.start_link(__MODULE__, "room1")
      {:ok, #PID<0.107.0>}
  """
  def start_link do
    # We register our registry (yeah, I know), with a simple name,
    # just so we can reference it in the other functions.
    GenServer.start_link(__MODULE__, nil, name: :registry)
  end

  @doc """
    ## Examples
      iex> Segway.Context.Registry.whereis_name("room1")
      :undefined
  """
  def whereis_name(room_name) do
    GenServer.call(:registry, {:whereis_name, room_name})
  end

  @doc """
    ## Examples
      iex> Segway.Context.Registry.register_name("room1", pid)
      :yes

      iex> Segway.Context.Registry.register_name("room1", pid)
      :no

      iex> Segway.Context.Registry.whereis_name("room1")
      #PID<0.107.0>
  """
  def register_name(room_name, pid) do
    GenServer.call(:registry, {:register_name, room_name, pid})
  end

  @doc """
    ## Examples
      iex> Segway.Context.Registry.unregister_name("room1")
      :ok

      iex> Segway.Context.Registry.whereis_name("room1")
      :undefined
  """
  def unregister_name(room_name) do
    GenServer.cast(:registry, {:unregister_name, room_name})
  end

  def send(room_name, message) do
    # If we try to send a message to a process
    # that is not registered, we return a tuple in the format
    # {:badarg, {process_name, error_message}}.
    # Otherwise, we just forward the message to the pid of this room.
    case whereis_name(room_name) do
      :undefined ->
        {:badarg, {room_name, message}}

      pid ->
        Kernel.send(pid, message)
        pid
    end
  end
  
  defp via_tuple(room_name) do
    # And the tuple always follow the same format:
    # {:via, module_name, term}
    {:via, Chat.Registry, {:chat_room, room_name}}
  end

  # SERVER
  def init(_) do
    {:ok, Map.new}
  end

  def handle_call({:whereis_name, room_name}, _from, state) do
    {:reply, Map.get(state, room_name, :undefined), state}
  end

  def handle_call({:register_name, room_name, pid}, _from, state) do
    # Registering a name is just a matter of putting it in our Map.
    # Our response tuple include a `:no` or `:yes` indicating if
    # the process was included or if it was already present.
    case Map.get(state, room_name) do
      nil ->
        {:reply, :yes, Map.put(state, room_name, pid)}

      _ ->
        {:reply, :no, state}
    end
  end

  def handle_cast({:unregister_name, room_name}, state) do
    # And unregistering is as simple as deleting an entry from our Map
    {:noreply, Map.delete(state, room_name)}
  end
end

an atom - the GenServer is registered locally with the given name using Process.register/2.

{:global, term} - the GenServer is registered globally with the given term using the functions in the :global module.

{:via, module, term} - the GenServer is registered with the given mechanism and name.

(The :via option expects a module that exports register_name/2, unregister_name/1, whereis_name/1 and send/2.)

via tuple (w/ Module that I want to use in order to register processes) 을 사용하여 다음과 같이 name option에 사용할 수 있다.

Process.register/2 는 locally 사용하는 경우 --> :atom만 name(key for pids)으로 사용할 수 있지만

:via or :global 은 remote node에서도 사용할 수 있다. --> any type(key for pids)으로 사용할 수 있다.

defmodule Chat.Server do
  use GenServer

  # API

  def start_link(name) do
    # Instead of passing an atom to the `name` option, we send 
    # a tuple. Here we extract this tuple to a private method
    # called `via_tuple` that can be reused for every function
    GenServer.start_link(__MODULE__, [], name: via_tuple(name))
  end

  def add_message(room_name, message) do
    # And the `GenServer` callbacks will accept this tuple the same way it
    # accepts a `pid` or an atom.
    GenServer.cast(via_tuple(room_name), {:add_message, message})
  end

  def get_messages(room_name) do
    GenServer.call(via_tuple(room_name), :get_messages)
  end

  defp via_tuple(room_name) do
    # And the tuple always follow the same format:
    # {:via, module_name, term}
    {:via, Segway.Context.Registry, {:chat_room, room_name}}
  end

  # SERVER (no changes required here)
  # ...
end

Ecto Composable Query

gozalex — Mon, 16 Nov 2020 17:55:42 +0900

medium.com/flatiron-labs/how-to-compose-queries-in-ecto-b71311729dac

How to Compose Queries in Ecto

Composable queries in Ecto including how to safely join through tables.

medium.com

Ecto.Query가 얼마나 Composable한가에 대한 짧은 토픽입니다.(구글 번역)

간단한 쿼리

좋습니다. 간단한 쿼리로 시작하겠습니다. 파란 차를 모두 찾아 봅시다. 이를 위해서는 Ecto.Query.where/3 만 있으면됩니다. 좋은 파이프 기능을 위해 키워드 구문과 달리 표현식 구문을 사용하는 것을 좋아하므로 앞으로 이러한 예를 살펴 보겠습니다. 이제 모든 파란색 자동차를 찾고 싶다고 말했지만이 기능을 좀 더 재사용 가능하게 만들어 모든 색상을 사용할 수 있도록하겠습니다. 이를 위해 다음과 같이 할 수 있습니다.

이제이를 시도해보기 위해 IEX 세션으로 이동하여 EctoCars.Car.with_color (“blue”) |> EctoCars.Repo.all ()을 실행하여이 쿼리를 시도해 보겠습니다.

def with_color(color) do
  Car
  |> where([c], c.color == ^color)
end

조인으로 쿼리

def with_transmission(type) do
  Car
  |> join(:left, [c], s in Specification, on: c.specification_id == s.id)
  |> join(:left, [c, s], t in Transmission, on: s.transmission_id == t.id)
  |> where([c, s, t], t.type == ^type)
end

이 작업을 수행하려면 실제로 두 번 query해야했습니다. specification을 통과 한 다음 다시 전송합니다. 우리는 Transmission type을 인수로 받아들이고 마지막에 where 절에서 이를 사용하여이 쿼리 함수를 다시 사용할 수 있도록했습니다.

주의해야 할 한 가지는 결합에 대한 세 번째 인수로 사용하는 문자 목록이 바인딩 된 변수 일 뿐이라는 것입니다. 예를 들어 두 번째 조인에서는 [c, s] 사용에 특별한 것이 없습니다. 이러한 문자는 이전 함수 호출에서 사용 된 것과 동일한 문자 였기 때문에 우리에게 의미가 있습니다. 두 번째 조인의 s를 다른 문자로 변경하면 쿼리가 전혀 변경되지 않습니다. (역자주1: 단, 순서는 중요합니다.!! [c, s] -> [a, b] 로 해도 상관 없습니다만 첫 번째가 Car이고 두 번째가 Spec. 이라는 것은 기억해야 합니다.)

콘솔에서 이것을 시도하면 다음을 볼 수 있습니다.

Composable 하게 만들기

이제 자동 변속기가있는 파란색의 모든 차를 정말로 찾고 있다면 어떨까요? 음, 완전히 새로운 쿼리를 작성하는 대신 기존의 두 쿼리 만 재사용 할 수 있다면 좋을 것입니다. 이렇게 하려면 유형 / 색상 인수뿐만 아니라 추가 할 기존 쿼리를 가져 오기 위해 함수를 약간 리팩터링해야 합니다.

첫 번째 인수를 선택 사항으로 설정하여 빌드중인 쿼리를 전달하도록 선택하거나 cars 테이블에서 쿼리를 기본적으로 수행하도록 선택할 수 있습니다. 이제

EctoCars.Car 
|> EctoCars.Car.with_color("blue") 
|> EctoCars.Car.with_transmission("automatic") 
|> EctoCars.Repo.all

하나의 긴 Ecto 쿼리를 작성하는 것처럼이를 연결할 수 있습니다.

여러 조인으로 작성

따라서 이전에했던 작업과 함께 엔진에 대한 쿼리 함수를 만들어 보겠습니다.

def with_engine_horse_power(query \\ Car, horse_power) do
  query
  |> join(:left, [c], s in Specification, on: c.specification_id == s.id)
  |> join(:left, [c, s], e in Engine, on: s.engine_id == e.id)
  |> where([c, s, e], e.horse_power > ^horse_power)
end

iex(10)> EctoCars.Car |> EctoCars.Car.with_color("blue") |> EctoCars.Car.with_transmission("automatic") |> EctoCars.Car.with_engine_horse_power(200) |> EctoCars.Repo.all()
** (Ecto.QueryError) lib/ecto_cars/cars/car.ex:37: field `horse_power` in `where` does not exist in schema EctoCars.Transmission in query:
from c0 in EctoCars.Car,
  left_join: s1 in EctoCars.Specification,
  on: c0.specification_id == s1.id,
  left_join: t2 in EctoCars.Transmission,
  on: s1.transmission_id == t2.id,
  left_join: s3 in EctoCars.Specification,
  on: c0.specification_id == s3.id,
  left_join: e4 in EctoCars.Engine,
  on: s1.engine_id == e4.id,
  where: c0.color == ^"blue",
  where: t2.type == ^"automatic",
  where: t2.horse_power > ^200,
  select: c0
(elixir) lib/enum.ex:1925: Enum."-reduce/3-lists^foldl/2-0-"/3
    (elixir) lib/enum.ex:1418: Enum."-map_reduce/3-lists^mapfoldl/2-0-"/3
    (elixir) lib/enum.ex:1418: Enum."-map_reduce/3-lists^mapfoldl/2-0-"/3

여기서 일어난 일을 분석 할 수 있는지 보겠습니다. 오류를 살펴보면 Transmission 스키마에 horse_power가 존재하지 않는다는 의미입니다. 이를 좀 더 잘 이해하기 위해 이러한 모든 쿼리 조각을 풀고 함수 외부에서 함께 작성해 보겠습니다.

Car
|> where([c], c.color == ^color)
|> join(:left, [c], s in Specification, on: c.specification_id == s.id)
|> join(:left, [c, s], t in Transmission, on: s.transmission_id == t.id)
|> where([c, s, t], t.type == ^type)
|> join(:left, [c], s in Specification, on: c.specification_id == s.id)
|> join(:left, [c, s], e in Engine, on: s.engine_id == e.id)
|> where([c, s, e], e.horse_power > ^horse_power)

여기서는 좀 더 쉽게 볼 수 있습니다. 결합이 join과 함께 작동하는 기본 방식으로 인해 참조하는 테이블은 해당 목록에서의 위치와 전적으로 관련됩니다. 따라서 8 행에서 engines 테이블에 대해 쿼리 할 때 실제로이 쿼리의 세 번째 테이블에 대해 쿼리합니다. [Trasnmission!!!] 이것을있는 그대로 작동 시키려면 다음을 수행해야합니다.

Car
|> where([c], c.color == ^color)
|> join(:left, [c], s in Specification, on: c.specification_id == s.id)
|> join(:left, [c, s], t in Transmission, on: s.transmission_id == t.id)
|> where([c, s, t], t.type == ^type)
|> join(:left, [c, s, t], e in Engine, on: s.engine_id == e.id)
|> where([c, s, t, e], e.horse_power > ^horse_power)

우선 사양에 대한 이중 조인을 제거했습니다. 실제로 누가 그것을 필요로하기 때문입니다. 또한 바인딩 목록이 Transmission에 대한 기존 바인딩을 인식하도록 엔진에 대한 조인 및 쿼리를 업데이트했습니다. 현재이 쿼리는 이전에 수행 된 쿼리 (사양에 따라)와이 쿼리를 호출하기 전에 동일한 수의 테이블이 쿼리에 조인되었는지에 따라 달라집니다. 동작은 하겠지만 만족스럽지 않습니다. 여기에 더 나은 방법이 있어야합니다.

Named Binding

Named Binding을 사용하려면 join을 호출 할 때 as 옵션을 전달합니다. join (query, : left, [c], s in Specification, as : : specifications, on : c.specification_id == s.id). 그런 다음 다음 키 사양을 사용하여 쿼리에서 사양 변수를 바인딩 할 수 있습니다. : join (query, : left, [c, specification : s], t in Transmission, as : : transmissions, on : s.transmission_id == t.id). 이제 명Named Binding을 사용하도록 함수를 다시 작성해 보겠습니다. (역자주2: as 옵션은 딱 2 군데서 사용합니다. join & from)

def with_transmission(query \\ Car, type) do
    query
    |> join(:left, [c], s in Specification, as: :specifications, on: c.specification_id == s.id)
    |> join(:left, [c, specifications: s], t in Transmission, as: :transmissions, on: s.transmission_id == t.id)
    |> where([c, transmissions: t], t.type == ^type)
  end

  def with_engine_horse_power(query \\ Car, horse_power) do
    query
    |> join(:left, [c], s in Specification, as: :specifications, on: c.specification_id == s.id)
    |> join(:left, [c, specifications: s], e in Engine, as: :engines, on: s.engine_id == e.id)
    |> where([c, engines: e], e.horse_power > ^horse_power)
  end

하지만 다시 연결하려고하면 흥미로운 일이 발생합니다.

iex(16)> EctoCars.Car |> EctoCars.Car.with_color("blue") |> EctoCars.Car.with_transmission("automatic") |> EctoCars.Car.with_engine_horse_power(200) |> EctoCars.Repo.all()
** (Ecto.Query.CompileError) alias `:specifications` already exists
    (ecto_cars) lib/ecto_cars/cars/car.ex:35: EctoCars.Car.with_engine_horse_power/2

동일한 키를 다시 바인딩 할 수 없습니다. 간단한 해결책은 with_engine_horse_power 함수에서 사양에 대한 조인을 제거하는 것이지만, 사양에 조인하는 함수가 호출 된 후에 만이 함수를 호출해야하는 위치에 다시 갇혀 있습니다.

여기에서 가장 좋은 방법은 쿼리가 이미 특정 테이블에 조인되었는지 확인하고 확인하지 않은 경우에만 다시 조인하는 것입니다. has_named_binding?으로 깔끔하게이 작업을 수행 할 수 있습니다. 이 함수를 사용하면 쿼리에 이미 해당 바인딩이 있는지 확인하고 확인할 수 있습니다.

def with_transmission(query \\ Car, type) do
    query
    |> join_specifications()
    |> join(:left, [c, specifications: s], t in Transmission, as: :transmissions, on: s.transmission_id == t.id)
    |> where([c, transmissions: t], t.type == ^type)
  end

def with_engine_horse_power(query \\ Car, horse_power) do
    query
    |> join_specifications()
    |> join(:left, [c, specifications: s], e in Engine, as: :engines, on: s.engine_id == e.id)
    |> where([c, engines: e], e.horse_power > ^horse_power)
end

defp join_specifications(query) do
    if has_named_binding?(query, :specifications) do
      query
    else
      query
      |> join(:left, [c], s in Specification, as: :specifications, on: c.specification_id == s.id)
    end
end

join_specifications 도우미 함수는 조인을 확인하고 필요한 경우 쿼리에 추가하는 작업을 담당합니다. 이제 마지막으로 특정 순서에 의존하지 않거나 두 번째를 호출하기 전에 항상 호출해야하는 하나의 함수에 의존하는 구성 가능한 쿼리를 작성할 수 있습니다!

iex(17)> EctoCars.Car |> EctoCars.Car.with_color("blue") |> EctoCars.Car.with_transmission("automatic") |> EctoCars.Car.with_engine_horse_power(200) |> EctoCars.Repo.all()
17:31:25.303 [debug] QUERY OK source="cars" db=2.6ms queue=3.8ms
SELECT c0."id", c0."color", c0."vin_number", c0."specification_id" FROM "cars" AS c0 LEFT OUTER JOIN "specifications" AS s1 ON c0."specification_id" = s1."id" LEFT OUTER JOIN "transmissions" AS t2 ON s1."transmission_id" = t2."id" LEFT OUTER JOIN "engines" AS e3 ON s1."engine_id" = e3."id" WHERE (c0."color" = $1) AND (t2."type" = $2) AND (e3."horse_power" > $3) ["blue", "automatic", 200]
[
  %EctoCars.Car{
    __meta__: #Ecto.Schema.Metadata<:loaded, "cars">,
    color: "blue",
    id: 3,
    specification: #Ecto.Association.NotLoaded<association :specification is not loaded>,
    specification_id: 1,
    vin_number: "my_dream_car"
  }
]

Ecto.Multi

gozalex — Tue, 6 Oct 2020 14:21:01 +0900

Ecto.Multi는 여러 Repo 작업을 그룹화하기위한 데이터 구조입니다.

Ecto.Multi은 가능한 하나의 데이터베이스 트랜잭션에서 수행하고 각 insert/update/delete등의 각 작업은 호출 시, 실행되지 않은 채로 MapSet에서 관리 되어야 합니다. 각 작업은 고유한 key를 가지며 성공 또는 실패의 경우에 그 결과를 식별하는 이름이 지정됩니다.

모든 작업은 추가 된 순서대로 실행됩니다.

%Ecto.Multi{}를 사용하여 유형 일치를 패턴화할 수 있지만 필드에 액세스하거나 직접 수정하는 것은 권장되지 않습니다.

Ecto.Multi.to_list / 1은 내부 검사에 사용할 수있는 구조의 표준 표현을 반환합니다.

      pills_attrs
      |> Stream.map(fn pill ->
        change_pill(prescription, pill)
      end)
      |> Stream.map(fn pill_changeset ->
        key = "pill:#{pill_changeset.changes.name}"
        Ecto.Multi.insert(Ecto.Multi.new(), key, pill_changeset)
      end)
      |> Enum.reduce(Ecto.Multi.new(), &Ecto.Multi.append/2)
      |> Repo.transaction()
      |> case do
        {:ok, _pill} -> {:ok, prescription}
        {:error, _failed_operation, failed_value, _changes_so_far} -> {:error, failed_value}
      end

Ecto.Multi 는 MapSet<>의 구현체입니다.

여러 개의 Multi를 만들어서 append 또는 prepend 하여 Repo.transaction/1 으로 한 번에 처리할 때 사용합니다.

Stream.map/3 등을 사용하여 Ecto.Multi를 manipulate하여 사용합니다.

혹시 이전 쿼리의 리턴 값이 다음 쿼리에 필요한 경우에는 다음과 같이 처리합니다.

Ecto.Multi.new()
    |> Ecto.Multi.insert(:insert_prescription, changes_prescription(user, doctor, prescription_attrs))
    |> Ecto.Multi.run(:insert_pills, fn _repo, %{insert_prescription: prescription} ->

		......

    |> Repo.transaction()
    |> case do
      {:ok, prescription} -> {:ok, prescription.insert_prescription}
      {:error, _failed_operation, failed_value, _changes_so_far} -> {:error, failed_value}
    end
    
    # prescription.insert_prescription로 빼낸 것을 주목하세요 ^^

Ecto.Multi.run/3 함수를 사용하면 이전 쿼리의 결과 값을 name key로 받아올 수 있습니다.

Ecto.Multi는 transaction이므로 한 번에 많은 데이터를 여러 쿼리를 사용해서 관리할 때 편합니다.

명시적으로 rollback함수를 호출할 수도 있습니다.

insert_all을 사용할 수도 있지만 이 경우에는 timestampt() 로 생성한 updated_at / created_at을 처리해 주지 않습니다.

History of Erlang

gozalex — Thu, 25 Jun 2020 13:53:35 +0900

Erlang

Wikipedia (2017a)에 따르면 Erlang은 "영원히 실행되는"동시 프로그램을 작성하도록 설계된 기능적 프로그래밍 언어입니다. Erlang은 현재 프로세스를 사용하여 프로그램을 구성합니다. 이러한 프로세스는 공유 메모리가 없고 비동기 메시지 전달을통해 통신하며, 운영 체제가 아닌 가벼운 언어에 속합니다.

Erlang은 또한 코드를 변경하고 패치를 “즉시” 추가하므로 런타임 중에 프로그램을 업데이트 할 수 있으므로 프로그램을 다시시작할 필요가 없습니다. 이러한 메커니즘은 논스톱 시스템을 구현하기위한 소프트웨어 구성을 단순화합니다. (Joe Armstrong. Erlang의 역사, Ericsson AB)

Erlang은 함수형 프로그래밍 언어 제품군에 속하므로 일상적인 개발 접근 방식과 방법에는 몇 가지 근본적인 차이점이 있습니다. Erlang의 모든 변수는 “Single-assign” 입니다. 즉, 변수가 특정 값에 할당되면 다른 값으로 다시 할당 할 수 없습니다. 비슷한 기능을 가진 다른 프로그래밍 언어에서 가장 가까운 예는 Java의 "final" 키워드입니다. 변수 재 할당이 없으면 언어의 루프 구성은 연속적인 반복에서 변수를 변경할 수 있는 방법이 없기 때문에 의미가 없습니다. 언어에서 루핑 메커니즘을 모방 할수 있는 모든 제어는 재귀 호출에 의해 수행됩니다. Erlang의 구문 및 내부 언어 기능 외에도 HTTP 및 SSH 클라이언트, 서버, SNMP 기능 및 내장 NoSQL 데이터베이스 서버를 포함하는 거대한 표준 라이브러리가 있습니다.

실제 Erlang 개발은 1986 년 Ericsson Computer Science 연구소에서 이루어졌습니다. 이 팀은 차세대 통신 제품을 프로그래밍하기에 적합한 프로그래밍 언어를 조사하는 임무를 부여 받았으며, 이들은 보다 나은 전화 통신 프로그래밍 방법을 제공해야했습니다. 당시 전화 응용 프로그램은 현재 사용중인 응용 프로그램과 매우 다릅니다. 그것들은 평범한 프로그래밍 언어들이해결하도록 고안된 많은 문제들을 가지고있었습니다. 이러한 응용 프로그램은 본질적으로 단일 동시성이 뛰어납니다

switch는 수만 또는 수십만 건의 트랜잭션을 처리해야합니다. 트랜잭션이 분산되고 소프트웨어는 내결함성이 높을 것으로 예상됩니다.

Joe Armstrong (Ericsson AB의 Erlang의 역사)은 다음과 같이 말합니다. “전화를 제어하는 소프트웨어에 장애가 발생하면신문에 기사가 납니다. 반면에 일반적인 데스크톱 응용 프로그램에 장애가 발생해도 신문에 기사가 나는 일은 발생하지 않습니다.”

전화 통신 응용 프로그램에서 발생하는 서비스 손실없이 시스템이 실행되는 동안 소프트웨어가 업데이트되는 것이 매우 중요합니다. 또한 "Soft real time" 도메인에서 작동해야 하며 일부 작업에는 엄격한 타이밍 요구 사항이 있지만 다른 클래스의 작업에는 타이밍이 더 간단해야 합니다.

Erlang의 또 다른 요구 사항은 가동 중지 시간이 거의 없어야 하는 것이었습니다. 당시 인터넷의 인기가 높아지고 중단 없는 서비스 가용성이 필요해지면서 Erlang이 해결할 수 있는 문제가 확대되었습니다. 예를 들어, 동적 코드 업그레이드를 사용하여 하루에 수백만 건의 요청을 처리하는 논스톱 웹 서버를 구축하는 것은 소프트웨어 교환을 제어하기 위해 소프트웨어를 구축하는것과 매우 유사합니다.

일반적으로 통화 제어용 소프트웨어는 프로토콜 메시지에 대한 응답으로 상태 전이를 수행하는 제한된 수의 상태 기기를 사용하여 모델링 됩니다. 소프트웨어 관점에서 볼 때 시스템은 매우 큰 병렬 프로세스 모음으로 작동합니다. 어느 시점에서든 대부분의프로세스는 메시지 수신 또는 타이머 트리거로 인한 이벤트를 기다리고 있습니다. 이벤트가 발생하면 프로세스는 어느 정도의계산을 수행하고 상태를 변경하며 다른 프로세스로 메시지를 보낸 후 다음 이벤트를 기다립니다. 계산에 소요되는 시간은 매우적습니다. 반면, 모든 스위칭 시스템은 수십만 개의 매우 가벼운 프로세스를 처리 할 수 있어야하는데, 각 프로세스는 거의 계산을 수행하지 않습니다. 또한 프로세스의 소프트웨어 오류로 인해 시스템이 충돌하거나 시스템의 다른 프로세스가 손상되지 않아야 합니다. 이 문제는 너무 많은 수의 프로세스가 있는 시스템에서 프로세스를 메모리 손상 문제로부터 보호해야한다는 점이었습니다. 포인터가 있는 언어에서는 프로세스의 메모리 하한을 할당하여 메모리 관리 하드웨어를 사용하여 프로세스를 서로 보호합니다. 또한 메모리가 개별 프로세스에 대한 권장 요구 사항은 매우 작을 수 있으며 메모리 보호 하드웨어없이 모든 프로세스에대한 모든 메모리가 동일한 주소 공간에 있을 수 있습니다. Erlang에서 프로세스는 실제로 기본 운영 체제가 아닌 언어 자체의일부입니다. 언어는 메모리 관리와 병렬 프로세스 간 보호를 모두 제공하기 때문에 운영 체제의 대부분의 서비스가 필요하지 않습니다. 하드웨어에 액세스하는 데 필요한 리소스 할당 및 장치 드라이버와 같은 다른 운영 체제 서비스는 C로 작성되며Erlang 런타임에 동적으로 연결됩니다.

프로그래밍 언어의 세 가지 속성은 동시 언어 또는 운영 체제의 효율적인 운영을 위한 핵심 요소였습니다.

1. 프로세스 생성 시간

2. 두 가지 프로세스간에 컨텍스트 전환 시간

3. 두 프로세스 사이의 메시지 복사 시간

Joe Armstrong (Ericsson AB Erlang의 역사)은 다음과 같이 말합니다.“Erlang의 가장 초기 모티브는“PLEX와 같은 것을만들어 일반 하드웨어에서 더 잘 실행하는 것” 이었습니다.

Erlang에 대한 아이디어는 PLEX 및 AXE 디자인에서 크게 상속되었습니다. PLEX는 AXE 전화 교환 전용의 특수 목적의 이벤트 중심 실시간 프로그래밍 언어입니다. 그러한 아이디어 중 하나는 코드를 “즉석에서” 변경할 수 있는 가능성이었습니다. 따라서 AXE는 수많은 전화 통화의 병렬 조작과 같은 "포인터"문제가 있었습니다. 각 호출에 대한 메모리 요구 사항은 가변적이며링크 된 목록과 포인터 조작을 사용하여 메모리가 할당되었습니다. 이로 인해 많은 오류가 발생했습니다. 이것은 Erlang에서 사용 된 프로세스 및 가비지 수집 메모리 전략에서 영감을 얻은 것입니다.

AXE / PLEX 문화에서 비롯된 최종 핵심 아이디어는 프로세스 나 하드웨어의 장애가 처리 중인 트랜잭션에만 영향을 미치고다른 모든 작업은 그대로 유지되고 실행되어야 한다는 것입니다. 이로 인해 Erlang 디자인이 단순화되고 프로세스 간 교수형 포인터가 제거되었습니다.

메시지 전달은 다른 프로세스의 메모리 공간 사이에 메시지 버퍼를 복사하여 구현되었습니다. 내결함성을 달성하기 위해 팀은오류 처리가 어려운 문제로 인해 프로세스간에 리소스를 공유한다는 모든 아이디어를 거부했으며 시스템의 다른 부분에서 문제가 발생하면 모든 프로세스에 계속 실행하기에 충분한 로컬 정보가 있어야한다고 결정했습니다. 따라서 시스템을 안정적으로 유지하기 위해 프로세스간에 데이터를 복사하여 다른 프로세스가 충돌하는 경우 프로세스가 자체적으로 계속 실행하기에 충분한데이터를 갖도록 했습니다.

AXE / PLEX 히스토리 및 내부 아키텍처로 인해 새로운 프로그래밍 언어마다 필요한 요구 사항 목록이 제공되었습니다. (Joe Armstrong. Erlang의 역사, Ericsson AB.)

이 목록에는 다음이 포함됩니다.

1. 매우 많은 수의 동시 활동 처리

2. 특정 시간 내에 특정 시점에 수행 할 작업

3. 여러 컴퓨터에 분산 된 시스템

4. 하드웨어와의 상호 작용

5. 매우 큰 소프트웨어 시스템

6. 기능 통합과 같은 복잡한 기능

7. 시스템을 중지하지 않고 소프트웨어 유지 관리 (재구성 등)

8. 엄격한 품질 및 신뢰성 요구 사항

9. 하드웨어 오류 및 소프트웨어 오류에 대한 내결함성

이러한 요구 사항은 매우 간단 했으며 기존 시스템은 이미 운영 체제 및 응용 프로그램 라이브러리에서 이미 일부를 해결했습니다. 그럼에도 불구하고 모든 요구 사항을 충족시키기 위해 당시 사용 가능한 모든 프로그래밍 언어로 통신 응용 프로그램을Proto-typing하는 실험을 계속하기로 결정했습니다.

본 문서는 Building Analytics Plugin for Erlang MQTT Broker by Damir Mustafin의 문서 중 일부를 번역하였습니다.

다음은 CentOS 8에 Erlang을 설치하기 위한 repo 설정입니다.

erlang.org에서 repo를 찾을 수 없어 rabbitmq의 repo를 사용한 모습입니다.

기존 방식으로 install 하면 많은 dependancy가 우선 해결되어야 합니다.

# In /etc/yum.repos.d/rabbitmq-erlang.repo

[rabbitmq-erlang]
name=rabbitmq-erlang
baseurl=https://dl.bintray.com/rabbitmq-erlang/rpm/erlang/23/el/8
gpgcheck=1
gpgkey=https://dl.bintray.com/rabbitmq/Keys/rabbitmq-release-signing-key.asc
repo_gpgcheck=0
enabled=1

Elixir를 소스로 인스톨 합니다

git clone https://github.com/elixir-lang/elixir.git

make clean test

Precompiled 버전으로 인스톨 합니다.

wget https://github.com/elixir-lang/elixir/releases/download/v1.10.4/Precompiled.zip

# vi /etc/profile
export PATH="$PATH:/usr/bin/elixir/bin
source /etc/profile

elixir -v

Raft Consensus Algorithm

gozalex — Thu, 25 Jun 2020 10:31:04 +0900

What is Raft?

Raft는 이해하기 쉽게 설계된 합의 알고리즘입니다. 내결함성과 성능면에서 Paxos와 같습니다. Raft가 더 많은 사람들에게 합의를 제공 할 수 있기를 희망하며이 더 많은 사람들이 오늘날 이용 가능한 것보다 다양한 고품질의 합의 기반 시스템을 개발할 수 있기를 바랍니다.

Hold on—what is consensus?

합의는 내결함성 분산 시스템에서 근본적인 문제입니다. 합의는 "값"을 공유하는 여러 서버를 포함합니다. 일단 값에 대한 결정에 도달하면, 그 결정이 최종입니다. 일반적인 합의 알고리즘은 대부분의 서버를 사용할 수있을 때 진행됩니다. 예를 들어, 2 대의 서버에 장애가 발생하더라도 5 대의 서버 클러스터가 계속 작동 할 수 있습니다. 더 많은 서버가 실패하면 진행이 중지되지만 잘못된 결과는 반환되지 않습니다.

일반적으로 내결함성 시스템을 구축하기위한 일반적인 접근 방식인 Replicated Machine과 합의가 이루어집니다. 각 서버에는 상태 시스템과 로그가 있습니다. 상태 머신은 해시 테이블과 같이 내결함성을 만들려는 구성 요소입니다. 클러스터의 소수의 서버에 장애가 발생하더라도 클라이언트가 신뢰할 수있는 단일 상태 시스템과 상호 작용하는 것으로 나타납니다. 각 상태 머신은 로그에서 입력 명령으로 사용됩니다. 해시 테이블 예에서 로그에는 set X to 3과 같은 명령이 포함됩니다. 합의 알고리즘은 서버 로그의 명령에 동의하는 데 사용됩니다. 합의 알고리즘은 상태 머신이 X에 3을 n 번째 명령으로 적용 할 경우 다른 상태 머신이 다른 n 번째 명령을 적용하지 않도록해야합니다. 결과적으로, 각 상태 머신은 동일한 일련의 명령을 처리하므로 동일한 일련의 결과를 생성하고 동일한 일련의 상태에 도달합니다.

Raft Visualization

브라우저에서 실행중인 Raft 클러스터는 다음과 같습니다. Raft가 작동하는 것을 보기 위해 상호 작용할 수 있습니다. 왼쪽에는 5 개의 서버가 표시되고 오른쪽에는 로그가 표시됩니다.

A node can be in 1 of 3 states:

Follower State

Candidate State

Leader State

Become a candidate

Become a leader

Append Entry Message within a hearbeat

Commit

Consensus - Log replication

Election Timeout - The election timeout is the amount of time a follower waits until becoming a candidate.The election timeout is randomized to be between 150ms and 300ms.

Send "Request Vote Message" to all nodes and waits...

Append Entries messages

Heartbeat timeout

Split Vote - Wait another term and re-vote

Log Replication with the exactly same as heartbeat flow

Commit -> Reply to the client

Partitioned Network

Can't replicate

Become a new leader due to "HIGHER TERM" and roll back

본 문서는 raft.github.io 를 번역하였습니다. raft.github.io 에 접속하면 시각화 도구를 이용하여 어떻게 Leader Election이 일어나는지 쉽게 이해할 수 있습니다.

RabbitMQ Clustering

gozalex — Thu, 18 Jun 2020 20:45:27 +0900

토끼

RabbitMQ는 Erlang으로 만든 Message Queuing Framework 이라고 할 수 있습니다.

공식 홈에 따르면 RabbitMQ는 다음과 같은 프로토콜을 지원합니다.

Which protocols does RabbitMQ support?

RabbitMQ supports several messaging protocols, directly and through the use of plugins. This page describes the supported protocols and helps differentiate between them.

AMQP 0-9-1 and extensions

RabbitMQ was originally developed to support AMQP 0-9-1. As such this protocol is the "core" protocol supported by the broker. All of these variants are fairly similar to each other, with later versions tidying up unclear or unhelpful parts of earlier versions. We have extended AMQP 0-9-1 in various ways.

AMQP 0-9-1 is a binary protocol, and defines quite strong messaging semantics. For clients it's a reasonably easy protocol to implement, and as such there are a large number of client libraries available for many different programming languages and environments.

AMQP 0-9-1 is the protocol used by RabbitMQ tutorials.

STOMP

STOMP is a text-based messaging protocol emphasising (protocol) simplicity. It defines little in the way of messaging semantics, but is easy to implement and very easy to implement partially (it's the only protocol that can be used by hand over telnet).

RabbitMQ supports STOMP (all current versions) via a plugin.

MQTT

MQTT is a binary protocol emphasising lightweight publish / subscribe messaging, targetted towards clients in constrained devices. It has well defined messaging semantics for publish / subscribe, but not for other messaging idioms.

RabbitMQ supports MQTT 3.1 via a plugin.

AMQP 1.0

Despite the name, AMQP 1.0 is a radically different protocol from AMQP 0-9-1 / 0-9 / 0-8, sharing essentially nothing at the wire level. AMQP 1.0 imposes far fewer semantic requirements; it is therefore easier to add support for AMQP 1.0 to existing brokers. The protocol is substantially more complex than AMQP 0-9-1, and there are fewer client implementations.

RabbitMQ supports AMQP 1.0 via a plugin.

HTTP and WebSockets

While HTTP is not really a messaging protocol. However, RabbitMQ can transmit messages over HTTP in three ways:

The Web STOMP plugin supports STOMP messaging to the browser using WebSockets.
The Web MQTT plugin supports MQTT messaging to the browser using WebSockets.
The management plugin supports a simple HTTP API to send and receive messages. This is primarily intended for diagnostic purposes but can be used for low volume messaging without reliable delivery.

엄청나군요.

RabbitMQ는 Erlang 기반이므로 기본적으로 멀티 호스트에서의 분산 처리를 지원합니다.

바로 이 점이 "Development Philosophy of Elixian" 이며 제가 Elixir를 선택한 이유이기도 합니다.

나중에 다시 언급하겠지만 Elixir / Erlang은 분산 처리 환경과 Fast Fail 이라는 두 가지 컨셉은 정말 다른 어느 언어보다도 훌륭하다고 생각합니다.

다시 본론으로 돌아와서...

RabbitMQ는 elixir에서 했던 것과 동일하게

Node.connect :"rabbit@host1" 처럼 간단한 함수 호출 하나로 호스트간의 연결을 유지시켜 줍니다.

(예: elixir 에서 Node Connect 할 때에 iex --name api@hole1 과 같이 접속하면 해당 노드와 connection이 이루어 집니다.)

Erlang은 이 기능에 대한 보안을 위해 RABBITMQ_ERLANG_COOKIE 를 설정하게 하는데요.

이게 docker-compose로 up 하다가 어이 없는 상황을 경험하게 됩니다.

아래와 같이 RabbitMQ 공식 이미지를 사용하였을 경우,

Host1에서는 Cookie가 설정한 값대로 잘 들어있지만 Host2와 Host3에서는 엉뚱한 값이 들어 있는 경우가 있습니다.

docker-compose exec rabbitmq01 cat ~/.erlang.cookie

"TLSD23932LKDX"

rabbitmqctl join_cluster 시에 아무리 시도를 해도 노드를 찾지 못해 애 먹었는데요.

실제로 docker-compose.yml 에서 cookie를 설정했기 때문에 아무런 의심 없이 모든 노드가 동일한 cookie를 가지고 있을거라 예상했지만 결과는 사뭇 달랐습니다.

결국엔 echo \"이것은 cookie 입니다.\" > ~/.erlang.cookie 로 업데이트 후, clustering 성공했습니다.

version: '3.8'

services:

rabbitmq01:

image: rabbitmq:3-management

container_name: rabbitmq01

hostname: hole1

environment:

- RABBITMQ_ERLANG_COOKIE="이것은 cookie 입니다."

- RABBITMQ_DEFAULT_USER="rabbit"

- RABBITMQ_DEFAULT_PASS="hole"

- RABBITMQ_NODE_NAME="rabbit@hole1"

- RABBITMQ_NODE_TYPE="queue-ram"

ulimits:

memlock:

soft: -1

hard: -1

volumes:

- ./config/rabbitmq.config:/etc/rabbitmq/rabbitmq.config

- ./config/definitions.json:/etc/rabbitmq/definitions.json

- ./data:/var/lib/rabbitmq

- logs:/var/log/rabbitmq

ports:

- 4369:4369

- 5671:5671

- 5672:5672

- 15672:15672

- 25672:25672

- 35197:35197

network_mode: host

restart: always

volumes:

logs:

driver: local

클러스터링이 성공하면 다음과 같은 로그가 나옵니다.

클러스터링 성공!!!

# 추가 1

기본적으로 네트워크는 모두 host를 사용하였으며

각각의 docker host 에서 /etc/hosts 파일을 다음과 같이 수정하였습니다.

(보안을 위해 ip / domain / alias는 실제와 다르게 변경하였습니다. 위의 로그와 다를 수 있음을 참고해주세요.)

10.10.120.11   api1.elixian.co.kr   hole1
10.10.120.12  api2.elixian.co.kr   hole2
10.10.120.13  api3.elixian.co.kr   hole3

설정을 변경한 뒤, 꼭 네트워크 호스트 데몬을 재시작 해줍니다.

systemctl restart systemd-hostnamed

# 추가 2

네트워크를 Host 로 사용하여 /etc/hosts 를 수정하면 container에서도 동일하게 적용됩니다.

만약 Bridge였다면 어땠을까요? ^^;;

테스트 해보지는 않았습니다만 link를 잡는다던가 network을 connect 한다던가하는 작업이 필요하지 않았을가 생각해 봅니다.

# 추가 3

인터넷을 뒤지다가 재미난 것을 발견했습니다.

http://tryrabbitmq.com

Try RabbitMQ 라는 사이트인데요.

다양한 Exchange Type과 Producer / Consumer / Queue를 배치해 보면서 어떻게 데이터가 흘러가는지 시각적으로 확인할 수 있습니다.

잘 만들었네요 ^^;;