openlang

합쳐진 메일박스 로그로 무엇을 알 수 있을까요?

부분 검토

일반 Erlang 메시지만 쓰고 우선순위 수신은 꺼져 있다고 할게요. 수신자 하나가 같은 패턴으로 네 이벤트를 모두 받아요. A는 A1 다음에 A2를 보내고, B는 B1 다음에 B2를 보내요.

같은 송신자가 보낸 신호의 순서는 유지돼요. A1, B1, B2, A2처럼 섞여도 두 송신자의 송신 순서는 모두 지켜져요. 하지만 B1이 A1 뒤에 있다고 해서, A1이 처리됐기 때문에 B가 행동했다고 볼 수는 없어요.

B1이 A1의 처리에 의존한다면 프로토콜이 그 연결을 확립해야 해요. 로그를 읽는 사람이 추측하게 두면 안 되겠죠. 도착 순서를 전역 인과 순서로 취급하기보다, 송신자별 순서 태그와 계기가 된 이벤트를 가리키는 명시적인 연결을 남기는 편이 더 정직한 로그가 되지 않을까요?

이어지는 대화 2

서로의 근거를 따라
  1. 고유 링크

    확인 메시지 하나로 대기 조건을 만들 수는 있어요. 그런데 무엇을 확인하나요? B가 A1의 적용 완료를 기다려야 한다면 수신 확인만으로는 부족해요. B가 A1을 명시한 완료 확인을 기다린 뒤, 그 ID를 B1에 넣게 하겠어요.

  2. 고유 링크

    ID를 보관할 공간도 필요하다. Odin으로 수집기를 만든다고 가정하면, 화면상의 위치를 연결에 쓰기보다 각 레코드에 이벤트 ID와 의존 대상 ID를 저장하겠다. 행을 다시 묶어도 관계는 유지되어야 한다.

    저장 공간의 수명도 여기에 맞춰야 한다. 동적 배열은 나중에 context.allocator가 바뀌어도 기존 할당자를 유지한다. 레코드가 임시 저장 공간의 텍스트를 참조한다면, 보관 중인 로그에 그 텍스트가 필요한 동안에는 해당 공간을 비울 수 없다.

같은 질문의 다른 갈래

  1. 캐시는 언제 준비됐다고 말할 수 있을까요?

    start_link라는 이름은 든든하지만, 이 호출이 반환됐을 때 클라이언트가 실제로 확인한 건 무엇일까요? 가상의 캐시 서비스에서 init이 {:ok, state, {:continue, :warm_cache}}를 반환해요.…

  2. 큐가 8칸이어도 고루틴 88개가 기다릴 수 있어요

    서버에 요청 100개가 한꺼번에 들어오고, 요청마다 작업이 하나씩 있다고 해 봐요. 워커는 4개, 채널에는 작업 8개가 들어갈 자리를 둬요. 요청이 몰리는 동안 끝나는 작업은 없다고 가정해요. 작업 4개는 실행 중이고 8개는…