一。为什么会讲到这个问题
那天写代码,调试完就扔到线上去了,结果运行中发现application的stop被调用了,原因是supervisor下的一个gen_server异常。
百思不得其解啊,gen_server配置了重启方式permanent,而且supervisor也填上了重启策略,但是日志中既没看到重启也没其他记录,只看到各个gen_server全部被stop。Reason=shutdown。
搞了一下午,翻手册,上网搜,改代码测,终于发现了原因。以下是分析:
1.Reason=shutdown可以知道是supervisor主动让各个gen_server退出。
2.supervisor退出是因为有一个gen_server内部调用terminate,有异常。
3.加上日志,发现其实那个异常的gen_server是被重启了的。
结论:supervisor下的某个gen_server异常后,supervisor尝试重启该gen_server,但是该gen_server的实现原因,这个状态下gen_server无法启动,启动失败,继续重启。supervisor在配置的时间内重启该gen_server到最大次数后,认为监督树有问题,主动让各个gen_server退出,并通知application的manager调用stop。
虚惊一场。
二。application
application需要配置一个app文件,文件内描述该application的各种参数,比如依赖app。
application的start方法有两个参数,第二个参数描述了重启方式
application的启动流程:节点启动时,加载代码,但是不运行。加载的时候,会根据app的描述分析依赖模块是否已经被加载(所以系统启动的时候,需要注意各个应用的启动顺序,否则会报错)。application behavior文件有两个回调:start和stop,start描述了supervisor。启动的时候调用该supervisor,完成系统启动。
start对返回值是有规格要求的:start(StartType, StartArgs) -> {ok, Pid} | {ok, Pid, State}
application的终止顺序需要与启动顺序相反。保证模块正常退出。
三。supervisor
这个好像需要注意的不多,按照手册把参数配好就行了。
init([]) -> {ok, {{one_for_all, 0, 1}, []}}.rabbitMQ的supervisor的init,很简单。