Adam, comments inline.
On Sat, Dec 24, 2011 at 7:04 AM, Adam Schepis <[email protected]>wrote:
>
>
> What is the difference between the different ways to send a command in
> riak_core_vnode_master?
> - command
> - sync_command
> - sync_spawn_command
>
A command is async and is typically how a request should arrive at vnode.
The sync_command is the same as command but now the caller (i.e. the caller
of sync_command) will block until a reply is delivered by the vnode.
Contrary to the comments in the code the master is _not_ blocked by the
reply (possibly a case of code and docs getting out of sync).
The sync_spawn_command, according to the comments, is supposed to be
sync_command but without the side effect of blocking the master. As I
said, my guess this is historical and docs have not been kept in sync with
code. The spawn command does two things differently: 1) it spawn_links a
new process and 2) it sends the msg to the vnode via send_all_state_event
which causes the event to be handled by the handle_event callback rather
than the current state (which is moot in riak_core_vnode since there is
only one state). Looking at Riak I see sync_spawn_command only used it two
places, both in riak_kv_vnode: 1) fold and 2) get_vclocks. In the case of
fold this is only used by the backup process (all other folds go thru a
different code path). I see get_vclocks referenced nowhere. It is my
opinion that this is legacy code that should be removed.
> as far as i can tell, the sync commands will hold up the Sender process
> until the Sender receives a {reply, Whatever, State}, whereas command is
> asynchronous and the Sender won't wait for a result. I returned noreply
> from a handle_command that was called by sync_spawn_command and it hung on
> the Sender side.
>
> Next, when is it appropriate to use reply and noreply in handle_command?
> Does no reply really mean there will never be a reply or just that it may
> come from someone else at a later time (e.g. async call)
>
It is useful to use noreply so that you may offload the request to another
process but at the same time unblock your vnode. I couldn't quickly find a
good example of this out in the wild, I would have thought listkeys does
something like this but it has it's own machinery which looks new.
It's also used in the case where a reply was already made in some helper
code. You can see this technique used in the KV_PUT_REQ code of
riak_kv_vnode.
Finally, maybe there is nothing to reply with.
> Finally, what is a Preflist? Is it just the list of preferred vnodes for a
> particular command (e.g. if nothing has crashed, here are the people who
> should see this.)
>
The preference list, or preflist for short, is the preferred vnodes to use
for a given operation. The notion of "preferred" comes from the idea of
_the ring_ and that in the best case you want to always send a particular
command to the same vnodes if possible. If the preferred vnodes aren't
available then you can look further down the list for secondary vnodes to
stand in place while the preferred vnodes are down or unavailable. If you
look at the core code you'll find the words "primary" and "fallback"
-Ryan
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
