"Forwarding" of gen_server calls?

[Francesco Cesarini]

> jim>[Okay, so it doesn't quite handle all error cases, since the original
> jim>gen_server caller will only catch 'EXIT' messages from the Pid of
> jim>the server it originally called.  I'm sure there are ways to deal
> jim>with this.]
> 
> Actually, in erlang-47.4.0, the client only detects timeouts and nodedowns
> in gen:call(). However, in R5B (the latest commercial release), and in the
> upcoming Open Source release, gen:call() uses a new one-way monitor
> function to make sure the server doesn't crash while processing the call.
> This is needed in order to avoid unnecessary latency.
> 
> The problem, from your perspective, becomes that the client will continue
> to monitor the first server, even though the call is passed to another
> server. A function like gen_server:tail_call() wouldn't be able to do much
> about that, since it would execute in a process other than the one doing
> the monitoring.

The above isn't an issue if you place S1 and S2 in the same supervisor
tree with a one-for-all or rest-for-one relationship (Where S2 is started
before S1) (Or have an application coordinator triggering a restart if
they are in different applications). As there is a clear dependency
between S1 and S2, if S1 exits abnormally, S2 should also be terminated
and restarted.

It is obvious that different process/application types have different
robustness requirements. I have however always pushed the idea that one
should always try to keep the restart strategy as simple as possible,
avoiding the handling of all special cases which can occur (And
decentralize in a generic module if some special cases have to be catered
for as they occur often), as these work arounds often lead to new bugs
instead of solving their predefined tasks. Thereof, if S2 exits, make S1
exit as well, and restart them. 

Cheers,
Francesco