Hi Joseph, Thanks for getting back with me, and my apologies that it's taken me so long to respond. Thank you for the explanation! You also came up with the right diagnosis of my problem. I fixed it sometime just before Christmas and everything has been working fine with riak_core since.
Once I get things together in a way that I like I'll be posting a public repo as another example of using riak_core for an application, and would certainly welcome any and all feedback. Cheers! Jeff On Tue, Dec 27, 2011 at 3:15 PM, Joseph Blomstedt <[email protected]> wrote: > Jeff, > > 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_kv_app.erl): > ===== > 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 > riak_core_vnode_proxy_sup:start_proxies. > > -Joe > > On Mon, Dec 19, 2011 at 10:52 AM, Jeff Thompson <[email protected]> > 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 > > [email protected] > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
