This article comes to an incorrect conclusion on the need for timeouts in Erlang's gen:call implementation. Monitors are necessary but not sufficient for building a robust distributed system with Erlang.
When dealing with remote processes a monitor is very quick to detect a process crash, however it can take a lot longer than 5 seconds to detect a node crash or other form of netsplit. Setting an application specific timeout in this case can be a prudent strategy for setting up a firebreak so that a netsplit does not cause cascading failures through the whole distributed system.
A case can also be made that just using monitors is not sufficient when talking with local processes. Monitors do not detect those situations when a process becomes unresponsive due to overloads like queue overrun. Once again it is a good idea to have a timeout in the call so that one may avoid a single misbehaving process crashing the whole system.
In fact, I find it difficult to imagine a situation where one would not want to have a timeout on a gen:call. That is why timeouts are set by default in the gen call facilities. Building highly concurrent systems is difficult. Erlang makes a lot of the typical pain points in building these systems go away. But the need to tune defaults and stress test a system remains.
1 comment
[ 3.3 ms ] story [ 16.6 ms ] threadWhen dealing with remote processes a monitor is very quick to detect a process crash, however it can take a lot longer than 5 seconds to detect a node crash or other form of netsplit. Setting an application specific timeout in this case can be a prudent strategy for setting up a firebreak so that a netsplit does not cause cascading failures through the whole distributed system.
A case can also be made that just using monitors is not sufficient when talking with local processes. Monitors do not detect those situations when a process becomes unresponsive due to overloads like queue overrun. Once again it is a good idea to have a timeout in the call so that one may avoid a single misbehaving process crashing the whole system.
In fact, I find it difficult to imagine a situation where one would not want to have a timeout on a gen:call. That is why timeouts are set by default in the gen call facilities. Building highly concurrent systems is difficult. Erlang makes a lot of the typical pain points in building these systems go away. But the need to tune defaults and stress test a system remains.