3 ms·

Tried reading through http://erlang.org/eeps/eep-0053.html http://erlang.org/eeps/eep-0053.html but couldn't grok it... The EEP dives right into the problem of

Tried reading through http://erlang.org/eeps/eep-0053.html http://erlang.org/eeps/eep-0053.html but couldn't grok it... The EEP dives right into the problem of "late replies" with little detail explaining the concept. I haven't ran into the problem the EEP is trying to solve but I am interested in understanding it. Can anyone provide more details on how a late reply emerges during gen_server client/server message passing and how an alias is intended to solve the issue? Is this only a problem with distributed messages? It looks like "late replies" are a problem under an additional constraint that's mentioned in the Motivation section, "When the author of the client code has full control over the client process such late replies can be handled without a proxy since the code can be aware of these potential stray messages and drop them when received." So.. you have a server sending messages over distributed erlang to a client that the author doesn't control which can risk receiving late messages if a connection is lost? Ugh.. what? I tried thinking about this from the proxy process angle as a solution to this mysterious problem, "Since the proxy process is not alive, a reply will be silently dropped and no stray message will reach the previous client of the request." But, if a "connection lost" event occurs, why would a message make it to the client to begin with? Why is the client still alive? If the connection is re-establish, then why drop the message? Wish the EEP more clearly articulated the class of bugs / issues its intending to address and when they occur.

toast0 6y ago
If you do gen_X:call and the timeout expires before you receive a response, you may still get a response later (late reply). The timeout case can happen without a connection loss or even without distribution. I believe gen_X:call sets a monitor (maybe a link?) though, so if the server process is distributed, and the connection is lost, the call will fail; however, the server does not set a monitor on the client (to my knowledge), so when it finishes processing the message, it will reply to the client; distribution may have already reconnected, or sending the reply may cause a reconnection. I don't have great knowledge on the monitor, where I worked, we used a modified call that didn't set monitors, because it was too much overhead; we relied on timeouts instead. If the call was part of a library function, you can return {error, timeout} or whatever, but the process you ran in will have that reply message in its mailbox, possibly forever if it only does selective receives. This will show up in your system as growing memory use, and slowing message processing (unless all of your messaging is selective receives with new references that benefits from the mailbox marking optimization). In the proxy process alternative, you would spawn a new process to do the gen_X:call, and message back to the real client process. Any late replies get discarded as the spawned process will be dead. But spawning a process isn't free, even if an Erlang process is much lower cost than an OS thread or process. Without looking at details of the implementation, using a process alias seems like a reasonable optimization.

toast0 6y ago

If you do gen_X:call and the timeout expires before you receive a response, you may still get a response later (late reply). The timeout case can happen without a connection loss or even without distribution. I believe gen_X:call sets a monitor (maybe a link?) though, so if the server process is distributed, and the connection is lost, the call will fail; however, the server does not set a monitor on the client (to my knowledge), so when it finishes processing the message, it will reply to the client; distribution may have already reconnected, or sending the reply may cause a reconnection. I don't have great knowledge on the monitor, where I worked, we used a modified call that didn't set monitors, because it was too much overhead; we relied on timeouts instead. If the call was part of a library function, you can return {error, timeout} or whatever, but the process you ran in will have that reply message in its mailbox, possibly forever if it only does selective receives. This will show up in your system as growing memory use, and slowing message processing (unless all of your messaging is selective receives with new references that benefits from the mailbox marking optimization). In the proxy process alternative, you would spawn a new process to do the gen_X:call, and message back to the real client process. Any late replies get discarded as the spawned process will be dead. But spawning a process isn't free, even if an Erlang process is much lower cost than an OS thread or process. Without looking at details of the implementation, using a process alias seems like a reasonable optimization.