As a project to better learn riak_core and to think more about distributed
problems, I've been writing a little mud app using riak_core.
I just updated to the latest riak_core version and am running into a
problem when riak_core_vnode_master gets a handle_cast.
In the previous version handle_cast would:
handle_cast(Req=?VNODE_REQ{index=Idx}, State) ->
Pid = get_vnode(Idx, State),
gen_fsm:send_event(Pid, Req),
{noreply, State};
get_vnode:
get_vnode(Idx, State=#state{vnode_mod=Mod}) ->
case idx2vnode(Idx, State) of
no_match ->
{ok, Pid} = riak_core_vnode_sup:start_vnode(Mod, Idx),
MonRef = erlang:monitor(process, Pid),
add_vnode_rec(#idxrec{idx=Idx,pid=Pid,monref=MonRef}, State),
Pid;
X -> X
end.
I would see the get_vnode code successfully start my vnode and the
subsequent gen_fsm:send_event/2 call would succeed.
However, the new version of get_vnode looks like:
handle_cast(Req=?VNODE_REQ{index=Idx}, State=#state{vnode_mod=Mod}) ->
Proxy = riak_core_vnode_proxy:reg_name(Mod, Idx),
gen_fsm:send_event(Proxy, Req),
{noreply, State};
and riak_core_vnode_proxy:reg_name/2 just returns an atom:
reg_name(Mod, Index) ->
ModBin = atom_to_binary(Mod, latin1),
IdxBin = list_to_binary(integer_to_list(Index)),
AllBin = <<$p,$r,$o,$x,$y,$_, ModBin/binary, $_, IdxBin/binary>>,
binary_to_atom(AllBin, latin1).
This is resulting in a:
{badarg,[{gen_fsm,send_event,2},
{riak_core_vnode_master,handle_cast,2},
{gen_server,handle_msg,5},
{proc_lib,init_p_do_apply,3}]}
Based on the above, there doesn't seem to be an 'on demand' starting of
vnodes anymore?
I'm happy to dig into this more (which I will anyway to learn whats going
on), but if there are any quick pointers that can be given as to how the
recent changes impact the writing of riak_core vnodes and what I'm seeing
above, I would certainly appreciate it.
Thanks!
Jeff
*
*
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
