On Wed, Feb 1, 2012 at 11:43 AM, Matthew A. Brown <[email protected]> wrote:
> Thanks much for the info. We're running Riak 1.0.3. I think in our
> case what would've made this easier to track down would have been not
> having the error output cut off in the log -- since the inputs to the
> reduce comprised a pretty large set, the output cut off before the
> call trace, which appears after the dump of the inputs. It was pretty
> easy to track down once I narrowed down the inputs to a manageable
> size that still reproduced the error.
Agreed - it's so hard to know how much context is useful, and how much
is too much. However, I think you'll find that the upcoming Riak 1.1
release already does much better in this situation.
I just created a small sample to reproduce what you found, where I
have a reduce function that calls bryan:does_not_exist/0, which is
undefined. In 1.0.3, as you reported, you see no indication of error
in the return value, and useless spew on the error console like:
13:26:43.720 [error] error:undef done():
[...so many inputs that the stack trace is omitted...
In the upcoming 1.1 release, using the HTTP interface at /mapred, you
receive a JSON object like:
{"phase":0,
"error":"{undef,[{bryan,does_not_exist,[]},{riak_kv_w_reduce,reduce,3},{riak_kv_w_reduce,done,1},{riak_pipe_vnode_worker,wait_for_input,2},{gen_fsm,handle_msg,7},{proc_lib,init_p_do_apply,3}]}"
"inputs":...}
As well as a much more informational message on the error console:
13:27:48.143 [error] gen_fsm <0.1484.0> in state wait_for_input
terminated with reason: call to undefined function
bryan:does_not_exist/0 from riak_kv_w_reduce:reduce/3
Hope this helps,
Bryan
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
