Question regarding recent riak_core_vnode_master changes

Joseph Blomstedt joe at
Tue Dec 27 16:15:17 EST 2011


There have been several changes to how vnodes are managed leading up
to the next release of Riak. One of those changes is the addition of
vnode proxy processes.

As before, vnodes are still started on demand. However, there are now
a set of vnode proxy processes that are always running. Unlike vnodes,
the proxy processes for all partition indices are started when a node
comes online, and the proxy processes are supervised and automatically
restarted if they crash. Each proxy process has a unique locally
registered name. To send an event to a vnode, you send it directly to
the proxy process for that vnode. If the proxy already has a pid for
the vnode, it forwards the message to the vnode. If it doesn't have a
cached pid, it will contact the 'riak_core_vnode_manager' to get a
vnode pid. If the vnode is currently running, the manager returns the
pid; otherwise it starts up the vnode and returns the newly spawned
pid. The same lazy / on-demand process as before.

The 'badarg' issue you are seeing is related to the relevant proxy
processes not being spawned for your vnodes before you try to send the
event, and therefore the constructed atom doesn't refer to a known
registered name. I am not sure how that is occurring, as vnode proxy
processes are automatically started the moment you register your vnode
module with riak_core. Of course, there has also been some changes to
have vnode are registered with riak_core as well. Make sure you are
registering your vnode with Riak using 'riak_core:register'. As an
example, here's how 'riak_kv' registers with riak_core (see in
riak_core:register(riak_kv, [
    {vnode_module, riak_kv_vnode},
    {bucket_validator, riak_kv_bucket}

You don't need a bucket_validator if your app isn't using one, but you
must always register your vnode_module. That call should trigger
'register_mod' in riak_core.erl that should trigger a call to


On Mon, Dec 19, 2011 at 10:52 AM, Jeff Thompson <mythrndr at> wrote:
> 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
> riak-users at

More information about the riak-users mailing list