Supervision Trees - A Beginner Writes

[Vance Shipley]

On Thu, Jan 15, 2004 at 11:05:54AM -0000, Gordon Guthrie, BTP, BT, SE wrote:
}  
}  This supervisor starts workers. The intention is that each worker will
}  eventually handle an http session, so I am starting them as transients.

Are you sure you want transients?  Will you actually be able to do
anything useful after a crash?  If not just use temporary and let 
the transactions fail.

}  These processes will die when the user session they support times out, so
}  each worker spawns a linked timeout process which periodically messages its
}  worker "if you haven't done anything since last time then exit".
  
Hopefully you are using a gen_server/gen_fsm behaviour for these workers.
You don't need another process handling timeouts.  Program your genserver_
call back module like this:

-behaviour(gen_server).

init(Args) ->
   ...
   Timeout = 10000, % ten seconds
   {ok, State, Timeout}.

handle_call(Request, From, State) ->
   ...
   {reply, Reply, NewState, Timeout}.

handle_info(timeout, State) ->
   ...
   {stop, timeout, NewState}.


}  The problem I have is that when the worker exits (either normal or a custom
}  timeout message) the supervisor and then the application both exit.
  
This is clearly because of MaxR and MaxT.

}  I can see that there might be circumstances that would kill a worker in
}  which a supervisor might also want to terminate for a clean restart.
  
This is what MaxR and MaxT are for.  Also if you need to coordinate 
between workers of the same supervisor you can use different restart
strategies.  If two worker processes are codependaent have them under
the same supervisor with a one_for_all restart stategy.  If either
exits both will be restarted.  

}  So my question is how do I (under OTP) handle the exit message that results
}  from the spawn_link to the child. In a 'homebrew' supervision tree (ie last
}  week) I would have just trapped exits...

You don't.  That's what supervisors are for. :)

	-Vance