Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync_spawn_command hangs for infinity if the vnode crashes or replies {stop, _, _} [JIRA: RIAK-2370] #807

Open
gatesn opened this issue Feb 2, 2016 · 2 comments

Comments

@gatesn
Copy link

gatesn commented Feb 2, 2016

When sending a sync_spawn_command I notice in riak_core_vnode.erl:345 that the {stop, Reason, NewModState} case doesn't reply to the sender. Given that riak_core_vnode_master:148 issues a sync_spawn_command with a timeout of infinity, the caller will hang forever.

A similar thing happens when the vnode crashes during a handle_command. Any other command being handled at the time of the crash will hang forever. I think the vnode_master ought to trap_exits to catch vnode crashes and reply({vnode_error, _} to the sender.

To reproduce:

handle_command(ping, _Sender, State) ->
timer:sleep(5000),
exit(crashing_the_vnode),
{reply, ok, State};

ping() ->
riak_core_vnode_master:sync_spawn_command(Idx, ping, ).

1> spawn(fun() -> :ping() end).
2> :ping().
...
CRASH REPORT ...
...

@Basho-JIRA Basho-JIRA changed the title sync_spawn_command hangs for infinity if the vnode crashes or replies {stop, _, _} sync_spawn_command hangs for infinity if the vnode crashes or replies {stop, _, _} [JIRA: RIAK-2370] Feb 2, 2016
@DeadZen
Copy link
Contributor

DeadZen commented Apr 30, 2016

@DeadZen
Copy link
Contributor

DeadZen commented May 3, 2016

I've verified this can happen, it occurs only under a specific condition where the indexes overlap...
And the index vnode dies during a prior request before the response of a current request completes, presumably because the dying vnode has no list of callers awaiting a response to be contacted during it's termination process... the question is should this behavior be modified?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants