rebar生成relup文件加载module顺序引发的erlan

2015-04-17  本文已影响176人  randyjia

rebar生成relup文件加载module顺序引发的erlang热升级失败

问题描述

12.19号，在对erlang应用做热升级的时候，升级失败，出错信息如下：
<pre><code>
escript: exception error: no match of right hand side value {error, {code_change_failed,<7845.1231.0>,hook_heroes_sup,
225273894003706867532273251651138786370, {'EXIT', {undef,
[{mongo_user_info,init,[],[]}, {hook_heroes_sup,init,1,
[{file,"src/hook_heroes_sup.erl"}, {line,44}]}, {supervisor,code_change,3,
[{file,"supervisor.erl"},{line,607}]}, {gen_server,system_code_change,4,
[{file,"gen_server.erl"},{line,685}]}, {sys,do_change_code,5,
[{file,"sys.erl"},{line,477}]}, {sys,do_cmd,6,[{file,"sys.erl"},{line,405}]}, {sys,handle_system_msg,8,
[{file,"sys.erl"},{line,318}]}, {proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]}}}}
</code></pre>

问题分析

出错信息分析

根据出错信息来看，主要是mongo_user_info的init方法没定义，而mongo_user_info的init()方法确实是这次热升级新加入的方法。

relup文件分析

查看relup文件，重点来看看和这次热升级失败有关的三个模块，这里一定要注意他们的出现的顺序。
<pre><code>
{"2.16",
[{"2.15.28",[],
[{load_object_code,{hook_heroes,"2.16",
[...,mongo_index,...,hook_heroes_sup,...,mongo_user_info,...]}},
...
{load,{mongo_index,brutal_purge,brutal_purge}},
...
{suspend,[hook_heroes_sup]},
{load,{hook_heroes_sup,brutal_purge,brutal_purge}},
{code_change,up,[{hook_heroes_sup,[]}]},
{resume,[hook_heroes_sup]},
...
{load,{mongo_user_info,brutal_purge,brutal_purge}},
...
[{"2.15.28",[],[point_of_no_return]}]}.
</code></pre>

2.15.8的hook_heroes_sup和2.16的hook_heroes_sup代码区别在于
增加了init方法中：
<pre><code>
mongo_index:init()
</code></pre>
mongo_index:init()方法实现如下：
<pre><code>
mongo_user_info:init().
</code></pre>
至此，可以从代码级别到relup文件理清楚了：mongo_index、hook_heroes_sup、mongo_user_info三个模块了，其中，hook_heroes_sup的行为模式是super_visor,是应用顶级监控树。

hook_heroes_sup依赖于mongo_index，mongo_index又依赖于mongo_user_info。
relup文件就是执行热升级顺序的文件，按照官方文档说明如下：
<pre>
The release upgrade file describes how a release is upgraded in a running system.
</pre>

分析为什么出错

看relup文件中hook_heroes_sup的操作：
<pre><code>
{suspend,[hook_heroes_sup]},
{load,{hook_heroes_sup,brutal_purge,brutal_purge}},
{code_change,up,[{hook_heroes_sup,[]}]},
{resume,[hook_heroes_sup]},
</code></pre>
首先挂起hook_heroes_sup这个进程，然后把新的hook_heroes_sup代码load进来，随后，执行supervisor的code_change方法。查阅源码
supervisor的code_change方法如下：
<pre><code>
code_change(_, State, _) ->
case (State#state.module):init(State#state.args) of
{ok, {SupFlags, StartSpec}} ->
case catch check_flags(SupFlags) of
ok ->
{Strategy, MaxIntensity, Period} = SupFlags,
update_childspec(State#state{strategy = Strategy,
intensity = MaxIntensity,
period = Period},
StartSpec);
Error ->
{error, Error}
end;
ignore ->
{ok, State};
Error ->
Error
end.
</code></pre>
看出来，当一个supervisor热升级的时候，会重新执行init()方法。那么问题来了，新的init()方法里面有mongo_index:init()代码，实际调用了mongo_user_info的init()方法，但是根据relup文件，
<pre><code>
{load,{mongo_user_info,brutal_purge,brutal_purge}},
</code></pre>
这个mongo_user_info的新代码加载，出现在新hook_heroes_sup加载的后面，自然，执行新的hook_heroes_sup的init()方法，是找不到新mongo_user_info的方法的。所以出错。
这里说明，rebar生成的relup文件，没有对这种类型的模块依赖做检查。

验证
深层次原因

从上面的分析，我们可以得到稍微抽象一点的描述，rebar生成热更新文件的顺序造成热升级失败问题：
暂且把这种依赖顺序称为"rebar-dead"依赖顺序。

这样的依赖顺序，rebar生成的relup文件就一定会报错。因为rebar生成的relup文件把新增的模块放在前面，修改的模块放在后面。

至于rebar生成relup文件的过程，和新增模块、删除模块、修改模块的顺序，后面会有详细分析。

如何避免

避免这类问题对热生级错误的方法有很多，分为代码、工具、运维三个层面

总结：

热升级对于使用erlang构建的游戏服务端应用来说，非常重要；每一次的热升级失败，都必须排查原因。后续肯定还有没有遇到的问题，还是要仔细分析。

上一篇 下一篇

猜你喜欢

热点阅读