前言

最近降级了otp24，一个提供地位无关call entity的组件在调用的entity过程退出时。会呈现timeout。在追究后发现和erlang otp24的一个改良相干。
https://www.erlang.org/blog/m...

起因

实现简述

在call一个entity时，不是间接call一个pid，而是通过节点的router转发：

sequenceDiagram    client->>+router: Request    router->>+entity: Request    entity-->>-router: Reply    router-->>-client: Reply

做过一个改良，由被调用的entity，间接返回。

sequenceDiagram    client->>+router: Request    router->>+entity: Request    entity-->>-client: Reply

在被调用的entity退出中时，须要由常驻的router返回client，entity在退出中。否则client会timeout。

sequenceDiagram    client->>+router: Request    entity->>+entity: terminate start    Note over entity: 音讯没有机会被解决    router->>+entity: Request    entity->>+entity: terminate end    client->>+client: timeout    

所以，router会monitor entity。在entity异样退出时，由router 返回client。问题也正呈现在这里。

问题根因

首先看erlang otp23的call代码：
gen.erl:202

do_call(Process, Label, Request, Timeout) when is_atom(Process) =:= false ->    Mref = erlang:monitor(process, Process),    %% OTP-21:    %% Auto-connect is asynchronous. But we still use 'noconnect' to make sure    %% we send on the monitored connection, and not trigger a new auto-connect.    %%    erlang:send(Process, {Label, {self(), Mref}, Request}, [noconnect]),    receive        {Mref, Reply} ->            erlang:demonitor(Mref, [flush]),            {ok, Reply};        {'DOWN', Mref, _, _, noconnection} ->            Node = get_node(Process),            exit({nodedown, Node});        {'DOWN', Mref, _, _, Reason} ->            exit(Reason)    after Timeout ->            erlang:demonitor(Mref, [flush]),            exit(timeout)    end.

在otp23中，咱们的代码运行如下。

sequenceDiagram    client->>+router: {Label, {client_pid, Mref}, Request}    entity->>+entity: terminate start    router->>+entity: Process.monitor ret Mref2    router->>+entity: {{client_pid, Mref}, {router_pid, Mref2}, Request}    entity->>+entity: terminate end    entity->>+router: {:DOWN, Mref2, down_type, entity_pid, reason}    router->>+client: {:DOWN, Mref, down_type, router_pid, reason}    

在音讯达到时，entity正好在退出中时，也能够将这个事件告诉client。
而otp24中，跨节点call如下：
gen.erl:223

do_call(Process, Label, Request, Timeout) when is_atom(Process) =:= false ->    Mref = erlang:monitor(process, Process, [{alias,demonitor}]),    Tag = [alias | Mref],    %% OTP-24:    %% Using alias to prevent responses after 'noconnection' and timeouts.    %% We however still may call nodes responding via process identifier, so    %% we still use 'noconnect' on send in order to try to send on the    %% monitored connection, and not trigger a new auto-connect.    %%    erlang:send(Process, {Label, {self(), Tag}, Request}, [noconnect]),    receive        {[alias | Mref], Reply} ->            erlang:demonitor(Mref, [flush]),            {ok, Reply};        {'DOWN', Mref, _, _, noconnection} ->            Node = get_node(Process),            exit({nodedown, Node});        {'DOWN', Mref, _, _, Reason} ->            exit(Reason)    after Timeout ->            erlang:demonitor(Mref, [flush]),            receive                {[alias | Mref], Reply} ->                    {ok, Reply}            after 0 ->                    exit(timeout)            end    end.

那么在otp24中，变成了这样：

sequenceDiagram    client->>+router: {Label, {client_pid, [alias | Mref]}, Request}    entity->>+entity: terminate start    router->>+entity: Process.monitor ret Mref2    router->>+entity: {{client_pid, [alias | Mref]}, {router_pid, Mref2}, Request}    entity->>+entity: terminate end    entity->>+router: {:DOWN, Mref2, down_type, entity_pid, reason}    Note over client: client期待的是Mref而不是 [alias | Mref]    router->>+client: {:DOWN, [alias | Mref], down_type, router_pid, reason}    client->>+client: timeout

修复就不言而喻了。

总结

erlang 的 Process aliases 是一个很棒的批改。解决了调用远端timeout后，音讯才返回的问题。timeout后才收到的返回，将被drop掉。这样catch住timeout也是平安的了。
举荐浏览之前写的另一篇blog：
谈谈erlang的timeout.